Horton

Re: Add support for logging the current role

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-16T21:24:32Z
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 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.

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