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
