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

On Thu, Oct 8, 2026 at 11:53 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> Few days ago maintainers of pgconsul (HA tool) asked me: how to wait until
> synchronous_stanby_names takes effect? For some reason they need to commit one
> transaction with full quorum. The best solution we found was to restart the node
> and insert\commit afterwards.

Our tests tend to restart to get around this problem, too, and that's
really heavyweight.

The oauth_validator test suite waits for lines in the logs to avoid
the restart penalty. But strictly speaking, it's waiting for the
*wrong* log line ("received SIGHUP, reloading configuration files").
That only works because the postmaster isn't multithreaded, and
knowing that the postmaster has started processing the SIGHUP is
enough to know that the next connection will pick up the new setting.
But I'm not really confident that all the happens-before logic shakes
out correctly in every corner case.

> So yeah, +1 for having synchronous reload.

What are the things we'd need to support for this to make sense as a
feature? I could see use cases for
- wait until new connections are guaranteed to see the new configuration
- wait until *all* backends are <ditto>

We would need to deal with concurrent changes/reloads correctly. Like,
I imagine no one's going to immediately demand "serializable
isolation", since the current architecture provides very few
guarantees, but it needs to make intuitive sense... If you make a
configuration change, and then sync-reload, you should see the result
of either your change or a change that came afterwards.

Thanks,
--Jacob