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
