Horton

Re: Add support for logging the current role

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-13T01:26:05Z
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

* Stephen Frost (sfrost@snowman.net) wrote:
> Erm, really?  Ok, fine, maybe you didn't have log_line_prefix set
> correctly the first time you needed the information, but after you
> discover that you *don't know*, you're going to be looking for an option
> to let you get that information for the future.  

Oh, yeah, and honestly, the above is the reason I'm after this myself- I
was having a difficult time figuring out which of 300-odd users a given
error was happening for and was annoyed that I couldn't figure out what
role it was.  The web server logs in with a 'general' role that doesn't
inherit anything and then has to 'set role' to whatever role the user
authenticated with.  After that 'set role' happens, we've got no way to
know from the logs who is impacted by a given error.

Guess I'm just trying to say that I didn't write this patch as an
academic exercise but rather because it solves a real world problem for
me.

	Thanks,

		Stephen