Re: Add support for logging the current role

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add support for logging the current role
Date: 2011-01-12 17:25:25
Message-ID: AANLkTi=k6Yqg9bhVodPJr3zqAmTz-L8BskrO+-HLsebX@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 12, 2011 at 12:13 PM, Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitriy Igrishin 2011-01-12 17:25:53 Re: libpq documentation cleanups (repost 3)
Previous Message Stephen Frost 2011-01-12 17:25:11 Re: Add support for logging the current role