Re: pg_reload_conf() synchronously

Hi,

On 2022-11-05 12:03:49 -0700, Gurjeet Singh wrote:
> For example, I thought of implementing DSM based synchronisation between
> processes, so that the invoking backend can be sure that _all_ children of
> Postmaster have processed the reload. But that will run into problems as
> different backends get created, and as they exit.

If you just want something like that you really can just use the global
barrier mechanism. The hard part is how to deal with situations like two
backends waiting at the same time. Possibly the best way would be to not
actually offer a blocking API but just a way to ask whether a change has been
processed everywhere, and require explicit polling on the client side.

> The proposed patch solves a specific problem, that of a single backend
> reloading conf before the next command, without adding any complexity
> for any other cases.

I'm not sure that's true btw - I seem to recall that there's code somewhere
noting that it relies on postmaster being the first to process a config
change. Which wouldn't be true with this change anymore. I remember not being
convinced by that logic, because successive config changes can still lead to
backends processing the config file first.

Greetings,

Andres Freund