Hi, On 2022-03-29 23:38:29 +0000, Jacob Champion wrote: > On Sat, 2022-03-26 at 11:36 -0700, Andres Freund wrote: > > > I also note that exposing it as a GUC means we have zero control over > > > who/what can read it. Maybe that's not a problem, but it needs to be > > > thought about before we go down that path. > > > > Yes, I think that's a fair concern. > > I like that there's no builtin way, today, for a superuser to modify > the internal value; it strengthens the use as an auditing tool. Moving > this to a PGC_SU_BACKEND GUC seems to weaken that. And it looks like > PGC_INTERNAL is skipped during the serialization, so if we chose that > option, we'd need to write new code anyway?
It'd be pretty simple to change can_skip_gucvar()'s selection of what to sync. E.g. an additional flag like GUC_PARALLEL_SYNCHRONIZE. I'm not convinced that a GUC is the answer, to be clear. > We'd also need to guess whether the GUC system's serialization of NULL > as an empty string is likely to cause problems for any future auth > methods. You can't represent a NULL in a postgres 'text' datum, independent of parallelism. So the current definition of pg_session_authn_id() already precludes that (and set_authn_id() and ...). Honestly, I can't see a reason why we should ever allow authn_id to contain a NULL byte. Greetings, Andres Freund
