Subject: Re: Custom oauth validator options

From: Jacob Champion <[email-masked]>
Date: Mon, 5 Jan 2026 10:53:06 -0800

On Thu, Dec 18, 2025 at 12:29 PM Zsolt Parragi
<[email-masked]> wrote:
>
> > I think I need to do more staring at the intersection of GUC
> > registration and session_preload_libraries, because my memory of the
> > order of operations was faulty. I won't be able to do that before the
> > holidays, most likely.
>
> Maybe I'm missing something, but why do we need
> session_preload_libraries?

Well, how do you want "global" GUCs registered by the validator to
behave when OAuth isn't used for the connection?

> The question is if non-validator libraries should be able to define
> PGC_HBA variables.

I think we should try for that, yeah. Otherwise I suspect considerable
pushback on the idea of modifying the GucContext enum for something
that can only be used by OAuth.

> * require session_preload_libraries. We proceed with authentication
> even with unresolved HBA variables, but abort the connection if there
> are still unknown parameters after loading session preload.

Of those choices, this _seems_ nicest. It'd be good to get a feel for
how it behaves in practice though.

Thanks,
--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Wed, 14 Jan 2026 18:20:05 +0000

> 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.

> how it behaves in practice though.

See the attached v2, with the above comment.

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.

---

From: Jacob Champion <[email-masked]>
Date: Thu, 15 Jan 2026 17:54:00 -0800

> 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.)

> See the attached v2, with the above comment.

Thank you!

> 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

---

From: Zsolt Parragi <[email-masked]>
Date: Fri, 16 Jan 2026 08:30:50 +0000

> want to know that my HBA is invalid when I reload, not later on down

Yes, I see that concern, but that's a bit trickier. To do that
properly we have to validate the variables, including their values,
not just their names. If we only validate the names, that doesn't
guarantee anything.

> and reload those libraries during SIGHUP, just to check GUC settings.

Would it be a good idea for it to dlopen/dlclose libraries? The
requirements of dlclose are not that strict, I'm not sure if it could
cause any issues. Opening a quick background process to verify it
seems safer, but even then, it could only verify the libraries
mentioned directly in the configuration.

I could write the code that does this for pg_hba on startup/reload,
but the tricky part is that we have to document that properly, to make
sure that the extensions also expects and handles the situation
correctly (that we try to validate gucs for all hba lines). Or start
one background process per hba line...

> good.

Yes, that would mean that. I'm not saying that would be
better/semantically correct, but technically it could also work,
that's why I mentioned it. The main use of PGC_HBA in this patch is to
add additional error reporting / separate what can be placed into
pg_hba. I could argue both for this approach and the opposite where we
allow other variables in pg_hba.

---

From: Jacob Champion <[email-masked]>
Date: Fri, 16 Jan 2026 08:39:04 -0800

> not just their names. If we only validate the names, that doesn't

Right. This goes back to your question upthread as to why I brought
session_preload_libraries into all this -- I thought
session_preload_libraries already had handling for this, but it
doesn't.

> Would it be a good idea for it to dlopen/dlclose libraries?

No, unfortunately.

> The
> cause any issues.

Last I knew (which was a while back), unloading a shared library tree
is fraught with peril, especially when you add dependency diamonds and
static initializers. I seem to remember that Windows, C++, and OpenSSL
all have particular areas of pain. My guess is that people are going
to make mistakes, leave dangling references around, and then either
crash the postmaster or (worse) copy a crashable address space into
every new backend.

And that's before you get into hooks and GUCs and etc. We used to have
a _PG_fini() callback for modules. It was disabled a long time ago
[1], then recently entirely removed from the codebase.

> that's why I mentioned it.

Okay, but that wouldn't be a committable change.

> The main use of PGC_HBA in this patch is to

Not sure what you mean by this (maybe once I can really test the
patch, I'll see?), but the reason I suggested placing PGC_HBA right
after PGC_SIGHUP is this: any SU_BACKEND or below variable seems
logically appropriate to set per HBA line, if the DBA wants (they're
all per-session), and anything SIGHUP or above is inappropriate/unsafe
(they're per-cluster). Does your patch disable the former?

[checks] Ah, it does prohibit those. Why?

--Jacob

[1] https://postgr.es/c/602a9ef5a7c60151e10293ae3c4bb3fbb0132d03

---

From: Zsolt Parragi <[email-masked]>
Date: Fri, 16 Jan 2026 17:13:52 +0000

> Last I knew (which was a while back),

Yes, I didn't want to say anything for sure, but I have similar
memories on Windows a while ago. I don't know anything for sure about
today, and especially on Linux, but delegating things to another
process seems to be a safer approach to me.

> [checks] Ah, it does prohibit those. Why?

Mainly because I couldn't decide where it should fit if the variable
is set at multiple places (or if we need multiple sources like
PGC_S_DATABASE_USER).

* A hba line can be completely generic, which should be above DATABASE
(ALTER DATABASE setting should override HBA setting, as it is more
specific)
* Or very specific about one user in one database using a specific
authentication method, which should be below DATABASE_USER as it is
more specific. (hba setting should override ALTER USER ... IN DATABASE
setting)

The first choice seems more logical to me, as that's how pg_hba is
usually used, but I thought this could still be confusing.

---

From: Jacob Champion <[email-masked]>
Date: Fri, 16 Jan 2026 09:52:11 -0800

> (ALTER DATABASE setting should override HBA setting, as it is more

I think settings in the database should override the ones from the
HBA, yes. So that would put PGC_S_HBA right between, what, _ARGV and
_GLOBAL?

> usually used, but I thought this could still be confusing.

I agree it could be, but is it any more confusing than if you were to
set work_mem in postgresql.conf today, and then `ALTER ROLE ALL SET
work_mem` to something completely different?

Usability improvements for that should be made GUC-wide, I think, and
not influence the chosen order of operations for this feature (as long
as there are no new security concerns). I don't want any project
veterans, whether DBAs or maintainers, to be surprised by how a new
GUC context behaves.

--Jacob