Re: Add support for logging the current role

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-17T16:51:48Z
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/17/2011 11:44 AM, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of sáb ene 15 00:34:40 -0300 2011:
>> Stephen Frost<sfrost@snowman.net>  writes:
>>> What about something other than
>>> version_x_y?  I could maybe see having a 'default' and an 'all'
>>> instead..  Then have the default be what we have currently and 'all' be
>>> the full list I'm thinking about.
>> If "default" always means what it means today, I can live with that.
>> But if the meaning of "all" changes from version to version, that seems
>> like a royal mess.  Again, I'm concerned that an external tool like
>> pgfouine be able to make sense of the value without too much context.
>> If it doesn't know what some of the columns are, it can just ignore them
>> --- but a magic summary identifier that it doesn't understand at all is
>> a problem.
> Maybe if we offered a way for the utility to find out the field list
> from the magic identifier, it would be enough.
>
> (It would be neat to have magic identifiers for "terse", "verbose",
> etc, that mimicked the behavior of client processing)
>

Just output a header line with the column names. We've long been able to 
import such files. If the list of columns changes we should rotate log 
files before outputting the new format. That might get a little tricky 
to coordinate between backends.

cheers

andrew