Re: Add support for logging the current role
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Robert Haas <robertmhaas@gmail.com>
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-16T22:55:14Z
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 →
-
Add support for an application_name parameter, which is displayed in
- 8217cfbd9918 9.0.0 cited
-
Make CSV column ordering a bit more logical.
- 230e8962f3a4 8.3.0 cited
-
Extend the format of CSV logs to include the additional information supplied
- 3bf66d6f1c3a 8.3.0 cited
-
Add virtual transaction IDs to CSVLOG output, so that messages coming from
- 77c166ba6cf6 8.3.0 cited
-
Provide for logfiles in machine readable CSV format. In consequence, rename
- fd801f4faa8e 8.3.0 cited
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. cheers andrew