Horton

Re: Add support for logging the current role

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-14T21:56:22Z
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 01/14/2011 11:48 AM, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Andrew Dunstan<andrew@dunslane.net>  writes:
>>> I think it's time to revisit the design of CSV logs again, now we have
>>> two or three releases worth of experience with it. It needs some
>>> flexibility and refinement.
>> It would definitely be nice to support optional columns a little better.
>> I'm not even sure whether the runtime overhead is worth worrying about
>> (maybe it is, maybe it isn't, I have no data).  But I do know that
>> adding a column to the CSV output format spec causes a flag day for
>> users.  How can we avoid that?
> My first thought would be to have a 'log_csv_format' GUC that's very
> similar to 'log_line_prefix' (and uses the same variables if
> possible..).  We could then ship a default in postgresql.conf that
> matches what the current format is while adding the other options if
> people want to use them.
>
> If we could have all the processing to generate that line go through the
> same function for log_line_prefix and log_csv_format, that'd be even
> better.  Makes me tempted to throw out the current notion of
> 'log_line_*prefix*' and replace it with 'log_line_*format*' to match
> exactly the 'log_csv_format' that I'm proposing.  That'd undoubtably
> cause more user headaches tho... :(
>
> 	


I'm not sure I really want to make it that flexible :-)

To deal with the issue Tom's referring to, I think it would be 
sufficient if we just allowed users to suppress production of certain 
columns (as long as we never do anything so evil as to add a new column 
in the middle).

There are some other issues with the format. I know Josh has bitched 
about the presence of command tags in certain fields, for example.

cheers

andrew