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

On 8 Oct 2026, Jacob Champion wrote:
> - wait until *all* backends are <ditto>

A synchronous reload that guarantees the new configuration for
subsequent connections would already be useful. My
synchronous_standby_names example needs more: walsenders and the
checkpointer also update shared sync-rep state after
ProcessConfigFile(). Acknowledging completion inside that function
would be too early.

Building on your generation idea, could we number reload requests and
acknowledge the number captured before reading the files? A request
arriving during a reload must not be satisfied by completion of that
older reload. We'd also need to distinguish completion from successful
application.

For testing, I posted a patch for filesystem-controlled wait injection
points in pgsql-bugs [0]. A waiting process publishes a PID file; TAP
can observe it and release the process by removing that file, without
SQL. With points around a backend's reload, we could hold it back while
the postmaster finishes, then test the two guarantees separately. The
posted series uses this to coordinate startup during crash recovery.

Thank you!

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/message-id/AE31E3B7-A21B-4C1C-B75B-8D542A9DC633%40yandex-team.ru