On Wed, Jan 14, 2026 at 10:20 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
>
> > Well, how do you want "global" GUCs registered by the validator to
> > behave when OAuth isn't used for the connection?
>
> My assumption was that with session_preload we only validate the line
> used for the current login, not all the lines. This way we don't have
> to always include all validator/hba plugins in session_preload, for
> every login.
>
> This is what I implemented for now, but if you think it would be
> better to validate every line, I can adjust that.
Let me think about that a bit, and look over your v2 approach; my
kneejerk reaction was that this is a dangerous situation to be in. I
want to know that my HBA is invalid when I reload, not later on down
the line.
But my understanding of GUCs from session_preload_libraries also had
some wishful thinking behind it. I believed that the situation today
was stricter than it actually is:
$ tail -2 data/postgresql.conf
session_preload_libraries = auto_explain
auto_explain.blahblahblah = yes
$ psql postgres
WARNING: invalid configuration parameter name
"auto_explain.blahblahblah", removing it
DETAIL: "auto_explain" is now a reserved prefix.
psql (18.0)
Type "help" for help.
And it makes sense that the postmaster is not going to somehow unload
and reload those libraries during SIGHUP, just to check GUC settings.
Hrmmm...
(If we did go in this direction, I think we might want to be
punishingly strict for the first iteration of the feature. PGC_HBA
providers should prefix their settings to avoid confusion and/or
future collisions anyway, so if we don't know what the GUC is, and its
prefix doesn't match either a validator name -- which is DBA-blessed
-- or a valid session_preload_libraries item, I'm not sure we should
even wait to complain.)
> > Of those choices, this _seems_ nicest. It'd be good to get a feel for
> > how it behaves in practice though.
>
> See the attached v2, with the above comment.
Thank you!
> Other than the above question (validate everything vs the current
> line), I'm also not entirely sure if we do need PGC_HBA. It could also
> work with PGC_SIGHUP + the new PGC_S_HBA value in GucSources.
I might be misunderstanding, but wouldn't that imply that DBAs could
now put every existing SIGHUP setting into HBA? That doesn't seem
good. My hope was that some existing SIGHUP variables could be
downgraded to HBA variables (say, gss_accept_delegation or
authentication_timeout -- though there might be a chicken-and-egg
issue for the latter?), but that's going to be a short list.
--Jacob
