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-12T17:13:47Z
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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Uh, did you actually stop to *think* about this patch?

Actually, I was worried about exactly that, but I didn't see anything at
the top of elog.c that indicated if it'd be a problem or not (and the
Syscache lookup issue was *exactly* what I was looking for). :(  There
was much discussion about recursion and memory commit and whatnot, but
nothing about SysCache lookups.

> What you have just committed puts a syscache lookup into the elog output
> path.  Quite aside from the likely performance hit, this will
> malfunction badly in any case where we're trying to log from an aborted
> transaction.

I had been looking into storing the current role inside the Proc struct
or in some new variable and then pulling it from there (updating it when
needed during a SET ROLE, of course), but it seemed a bit of overkill if
it wasn't necessary (which wasn't obvious to me). We could also just log
the role's OID (%o anyone..?), since that doesn't need a syscache lookup
to get at.  I'd much rather log the role name if we can tho.

I had looked through some of the other calls happening in log_line_prefix
and didn't see any explicit syscache lookups but it seemed like we were
doing quite a few other things that might have issues, so I had assumed
it'd be alright.  Sorry about that.

	Thanks,

		Stephen