On Wed, Jan 12, 2011 at 12:13 PM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
