Horton

Re: Add support for logging the current role

Robert Haas <robertmhaas@gmail.com>

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

Logging the OID seems to be of questionable value.  I thought of the
update-the-variable-when-it-changes approach too, but besides being a
bit expensive if it's changing frequently, it's not necessarily safe
to do the syscache lookup there either - see the comments for
GetUserIdAndSecContext (which are really for SetUserIdAndSecContext,
but they're in an odd place).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company