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
