Re: Add support for logging the current role

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> It seems there's at least one more thing to worry about here, which is
> the overhead of this computation when CSV logging is in use. If no
> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> will call show_role(), which will return "none". We'll then strcmp()
> that against "none" and decide to call show_session_authorization(),
> which will call strtoul() to find the comma separator and then return
> a pointer to the string that follows it. Now, none of that is
> enormously expensive, so maybe it's not worth worrying about, but
> since logging can be a hotspot, I thought I'd mention it and solicit
> an opinion on whether that's likely to be a problem in practice.

Well, in the first place, going through two not-very-related APIs in
order to reverse-engineer what miscinit.c already knows is pretty silly
(not to mention full of possible bugs). We ought to be looking at the
GetUserId state directly.

Now you will complain that elog.c mustn't try to map that OID back to
string form, which is true. But IIRC, we used to keep the current
userid stored in both OID and string form. The string form was removed
as unnecessary overhead, but maybe it'd be a good idea to put that back.

In short, add a bit of overhead at SetUserId time in order to make this
cheap (and accurate) in elog.c.

regards, tom lane