On Mon, Jan 19, 2026 at 12:30 PM Zsolt Parragi <[email protected]> wrote: > This is again a bit of a different topic, but I could make that a > proper patch from this prototype.
Let's separate the "verify session-preloaded GUCs" question from this feature request, yeah. > 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. 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
