Subject: Re: Custom oauth validator options

From: Zsolt Parragi <[email-masked]>
Date: Mon, 19 Jan 2026 20:30:04 +0000

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

I would say yes, because in the ALTER ROLE case, it's clear that a
role specific setting is more specific. But I also understand this
reasoning, I'll update the patch to follow this approach.

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

I looked into the previous idea I mentioned, about using child
processes for the purpose, and got that working.

* to prevent pg_hba reloads if something is invalid in it
* possibly to print out a warning (or error/fatal) during postmaster
startup along/instead of the connection warning
* possibly to do the same during sighup

The "instead of connection warning" (removing the placeholders from
postmaster) part is a bit complex or limited, as the postmaster can't
use dsm, and there can be any number of variables.

This is again a bit of a different topic, but I could make that a
proper patch from this prototype.

The important part for this thread is that if you would prefer a
version which completely verifies the pg_hba configuration before
accepting it, it's not that difficult to implement, or at least it's
not as complex as I originally imagined it. But even that won't
guarantee that the configuration always remains valid, because session
preload libraries can change without a server restart/reload... but
that's a rare corner case, and it could be a useful check most of the
time.

---

From: Jacob Champion <[email-masked]>
Date: Tue, 20 Jan 2026 10:02:16 -0800

> proper patch from this prototype.

Let's separate the "verify session-preloaded GUCs" question from this
feature request, yeah.

> that's a rare corner case, and it could be a useful check most of the

Right. I've been thinking about strategy here, and I'm not sure I've
solidified my thoughts yet, but I don't want to make you wait for
that. So here goes:

The inability to verify the HBA settings, without actively loading the
extension, is a drawback whether we introduce a PGC_HBA or not. I feel
pretty strongly that we can't require shared_preload_libraries for
this use case. And given the choice between "you cannot modify per-HBA
settings at all" and "we can't tell you until you test them whether
they're valid or not", most people would probably prefer the latter
limitation. Especially since the *values* for many existing HBA
parameters cannot truly be "validated" without testing anyway;
consider ldapserver etc.

Since session_preload_libraries already can't do this, I don't feel
too bad about us not doing it for a first version of the feature, but
this limitation is likely to remain for a long time. Unless you think
that there's a technical solution where the benefit easily outweighs
the maintenance cost. And my guess is that this conversation is about
to collide at high speed with the Postgres-threading work that's in
progress.

I like the idea of a PGC_HBA. I think it makes a lot of sense to be
able set other GUC overrides here -- authentication_timeout,
log_connections, pre/post_auth_delay. It seems architectually sound
and generically useful.

I'm worried that it's about to make a different decision from the
decision that is being made for the pg_hosts.conf file for SNI. So
this is not going to feel cohesive at first, and that's only "okay" if
it becomes cohesive very quickly, which requires a larger audience.

I'm also worried about namespace collisions between GUC and HBA. If we
scope it to OAuth then that becomes easier (e.g. just prepend
`validator.` or something to the setting name in HBA and then it's
obvious what's going on). But if someone decides in PG20 that
pam_use_hostname is a good GUC name for something, we're in trouble,
because the existing HBA options do not plug into the GUC system.

That's a lot of risk. High revert potential without multiple
maintainers saying "yes", IMO, and if that happens we will have no
improvement here for PG19.

So,
1) how close to the sun do you feel like flying today?
2) do you agree with the above?
3) can your option (b) or (c) make enough use of existing GUC
infrastructure, so that a future PGC_HBA could easily subsume an
OAuth-specific solution, if people want to continue down that path in
a less OAuth-centric thread?

--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Tue, 20 Jan 2026 20:31:11 +0000

> I'm not sure I've solidified my thoughts yet

I can wait if you would prefer more time to think about the problem, I
can work on other things in the meantime and we still have several
months before the code freeze. I mainly wanted to share my findings
with this experiment, and that was also a fun side project to try.

> 2) do you agree with the above?

Yes. I'm fine with not verifying everything perfectly (or as close as
perfectly as we can). I like my currently submitted version better
than the child process verification version, but I wanted to see if it
is doable or not, and to see what challenges there are.

> But if someone decides in PG20 that

We could make them reserved names? Or maybe even accessible as GUC
variables, even if we leave the current parsing/validation logic as
is. Making them proper GUC variables seemed like a clear follow up
patch to me, even if not for pg19.

> decision that is being made for the pg_hosts.conf file for SNI.

I probably should read that thread in more detail, but I assume that
your worry is about pg_hosts being a hardcoded configuration instead
of using a similarly customizable GUC context? Shouldn't that be
fixable in the future similarly?

> a less OAuth-centric thread?

I'm not sure about reusing existing GUC infrastructure, but  I could
make it look similar from the users perspective for example by adding
a function DefineCustomValidatorStringVariable that has a similar
interface to DefineCustomStringVariable, and in the future, this
function could simply forward to DefineCustomStringVariable.

That would limit the variable to be only definable in pg_hba, not
postgresql.conf, but otherwise should work similarly for
validators/users.

I think this would be a larger patch than the real PGC_GUC, but it
would be limited to the pg_hba parser.

> 1) how close to the sun do you feel like flying today?

Now that I have tried the PGC_HBA approach, I like how that works and
integrates with everything, this is a much better solution than my
original ideas.

On the other hand, it would be great to get something working in PG19.
By that time more libraries/tools should actually start to support
oidc, and we will see more use of the feature, and the way we
configure these parameters is important for the validators.

---

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

On Tue, Jan 20, 2026 at 12:31 PM Zsolt Parragi
<[email-masked]> wrote:
> We could make them reserved names?

I'm wondering if we should maybe do the opposite, and namespace the
GUCs instead? The vast majority of settings in an HBA are not going to
be GUCs, they're going to be method-specific parameters. So maybe it's
okay to have to do more typing to do the uncommon thing, and reference
them like `guc.log_connections` or something.

> Or maybe even accessible as GUC

Hmm... we may want to discuss my (e) option derailment more seriously,
if we're planning to go in that direction (and if other people like
that direction).

> fixable in the future similarly?

"Fixable" in what sense? pg_hosts.conf is currently similar to
pg_ident.conf in that it has no place for key=value pairs, and if you
add them after as an optional "column" for compatibility, you still
have to write something for all of those columns that you were trying
to replace with the GUC settings.

> function could simply forward to DefineCustomStringVariable.

Might work, yeah.

--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Mon, 26 Jan 2026 09:51:02 +0000

> if we're planning to go in that direction (and if other people like

I know you wrote that you are only half serious about it, and I
definitely do not want to go in the "lets completely refactor pg_hba
in this patch" direction, but keeping that idea in mind seems like a
good idea to me. The choosing authentication method part would already
be useful with OAuth, and now Joel also started a thread about fido2,
which also brings the question of MFA. Pluggable generic
authentication would also require generic GUC variables at this level.

Scoping validators to a specific prefix fixes the collision issue, but
it also goes in a different direction. Because of this I like the
other alternative idea (DefineCustomValidatorStringVariable) better,
if we want to go with a smaller change for this, but I still have to
implement that and see how it behaves in practice.

> to replace with the GUC settings.

pg_hba has the same issue, even if it has custom key=value data
already. What I meant is similarly how we could turn currently hard
coded pg_hba settings into GUC variables, the same is doable with
pg_hosts, either at a separate level or integrating it into the HBA
context. And later either both should get a new line style and
deprecate the old one, or maybe these settings should be configured
completely differently.

---

From: Jacob Champion <[email-masked]>
Date: Tue, 27 Jan 2026 09:40:32 -0800

On Mon, Jan 26, 2026 at 1:51 AM Zsolt Parragi <[email-masked]> wrote:
> The choosing authentication method part would already
> which also brings the question of MFA.

Or just the ability to offer a choice between two authentication
methods for a single user, yeah.

> deprecate the old one, or maybe these settings should be configured

Sure; at this point I think we're violently agreeing. If we suspect
the configuration UX needs to be refactored, that's not going to be a
decision made unilaterally in this thread, which is why I said I was
worried about the scope creep.

--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Wed, 28 Jan 2026 16:04:49 +0000

I implemented a DefineCustomValidatorStringVariable PoC - I don't like
it that much. It adds too much boilerplate code for a very specific
feature. If you say we should go with a more limited approach, I think
my earlier simple version is better, because it is simple. I'll also
try to think about other approaches.

And also let me go back to my concern that

> it also goes in a different direction.

I wrote this because of the simple "guc.some_name" example, as the
fixed guc prefix - and previously I also looked into
MarkGUCPrefixReserved, and I realized that there's no easy way to use
that for enforcing prefixes for a library.

And then I realized that maybe that needs an improvement, the behavior
of MarkGUCPrefixReserved and DefineCustom*Variable seems like a legacy
thing and not something that was intentionally designed that way.

What do you think about the following patches?

0001: defines a new guc, guc_prefix_enforcement that potentially
changes the behavior of prefix reservation. It has a few modes, based
on which missing prefix reservations or variables defined outside the
reserved prefix result in warnings or errors during library load time.
This is unrelated to pgc_hba, and applies to all custom variables.

0002: the same patch as before, with your comment (su_backend,
backend, suset, user can be set in pg_hba) addressed, and also always
enforces proper prefix reservation for pg_hba variables using 0001.

* We don't have to worry about collisions, because prefixes are always
enforced in pg_hba, so people can't "redefine" the fixed key/value
pairs or columns
* It also introduces the idea of enforcing guc prefixes for
extensions. In theory this setting should start with a relaxed default
(I would say warning mode), and changed to strict in a later major
version, enforcing proper guc rules by default. That way, third party
extensions won't be able to define gucs like pam_use_hostname.

I realize that

1. This is also scope creep
2. 0001 probably should be a separate thread/discussion

But I first wanted to ask your opinion about the idea / what do you
think about the interaction of the two patches.