Horton

Re: Add support for logging the current role

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-14T23:48:18Z
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 05:08 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> On 01/14/2011 11:48 AM, Stephen Frost wrote:
>>> 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.
>> I'm not sure I really want to make it that flexible :-)
> It actually sounded like a pretty good idea to me.  The current CSV
> format is already overly bulky/verbose, because it includes absolutely
> everything anybody ever wanted before now.  Allowing people to select
> what they actually need, and thereby get rid of some of the overhead
> they're currently paying, would be a good thing.
>
> 			


If you have a format string, what do you want to do with the bits of the 
format that aren't field references? What about delimiters? A format 
string makes it too easy to muck up and too hard to get right, IMNSHO. 
History has shown how easy it is to muck up CSVs.  The suggestion I made 
of allowing people to suppress production of certain columns would take 
care of the bulk problem much more safely, I think. We've actually had 
remarkably few issues with CSV logs not being loadable, that I know of 
anyway. When we implemented it, I expected many more issues with it than 
we've had. I'd like to keep it that way.

cheers

andrew