Horton

Re: Add support for logging the current role

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Stephen Frost <sfrost@snowman.net>, Tom Lane <tgl@sss.pgh.pa.us>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-17T00:07:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add support for an application_name parameter, which is displayed in

  2. Make CSV column ordering a bit more logical.

  3. Extend the format of CSV logs to include the additional information supplied

  4. Add virtual transaction IDs to CSVLOG output, so that messages coming from

  5. Provide for logfiles in machine readable CSV format. In consequence, rename

On Wed, Feb 16, 2011 at 5:55 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> On 02/16/2011 04:24 PM, Robert Haas wrote:
>>
>> On Tue, Feb 15, 2011 at 1:02 PM, Stephen Frost<sfrost@snowman.net>  wrote:
>>>
>>> * Andrew Dunstan (andrew@dunslane.net) wrote:
>>>>
>>>> On 02/15/2011 11:13 AM, Stephen Frost wrote:
>>>>>
>>>>> Think I suggested that at one point.  I'm all for doing that on a major
>>>>> version change like this one, but I think we already had some concerns
>>>>> about that on this thread (Andrew maybe?).
>>>>
>>>> I could live with it for a release if I thought we had a clear path
>>>> ahead, but I think there are some design issues that we need to
>>>> think about before we start providing for header lines and variable
>>>> formats in CSV logs, particularly w.r.t. log rotation etc. So I'm
>>>> slightly nervous about going ahead with this right now.
>>>
>>> I believe the suggestion that Robert and I were talking about above was
>>> to just unilatterally change the CSV log file output format to include
>>> current_role.  No header lines, no variable output format, etc.
>>>
>>> I do think we can make header lines and variable output work, if we can
>>> get agreement on what the semantics should be.
>>
>> I think we're back to not having a consensus on a reasonable way to
>> proceed here.  Let's take this up again for 9.2.
>>
>
> That's up to you. I can certainly live with what is suggested in Stephen's
> penultimate para above.

OK.  If no one objects further, Stephen and I will make that happen.
Otherwise: he's dead, Jim.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company