Do we want to solve reload/config races more generally? (was: Postmaster crashes on SIGHUP when oauth_validator_libraries holds only whitespace)

On Wed, Sep 30, 2026 at 11:20 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> On Wed, Sep 30, 2026 at 11:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> > The test addition coined with bca67e5a3 is not very robust,
> > unfortunately. Buildfarm animal serinus found a way to break it [1]
> > as below:
>
> Bleh. These SIGHUP/log file races are really annoying, and I'm going
> to need to trawl the list to see if anyone's proposed a more general
> solution. (I keep thinking about assigning an xid as a generation
> number to an in-memory configuration...)

Moving over to -hackers in case anyone has thoughts. I notice [1]
touched on a similar thing, only with pg_ident/hba.

The general issue, for anyone new to the problem, is that reloading
doesn't wait for the effects of the SIGHUP to complete. (And the
meaning of "complete" depends on the test case.) It feels like this
would pop up in more situations, but the buildfarm doesn't always show
it and it's an easy trap to fall into.

Outside of development, it really seems like a DBA would like to say
"I reloaded the server using <some command> and it succeeded, so now I
_know_ that my changes have been applied."

> For now, is the following test giving us much, or can we remove it?
> We've already done the wait_for_log(). If that "sequence point" turns
> out to be inadequate for some other reason, we'd have to fix it
> anyway.
>
> > is($bgconn->query_safe('SHOW oauth_validator_libraries'),
> > 'validator', 'oauth_validator_libraries restored');

I just pushed a commit removing this check. (We don't need the $bgconn
backend to reflect the current state. We only care that _new_ backends
will adopt the new setting.)

Thanks,
--Jacob

[1] https://postgr.es/m/CAJTYsWWGXJRhefkYs6wZFUOHqE9k5VSoABH2uzke5FMBSmE0%3Dw%40mail.gmail.com