On Sat, Nov 5, 2022 at 11:23 AM Andres Freund <and...@anarazel.de> wrote: > > As far as I know, Gurjeet has been annoyed only with non-user-settable > > GUCs for one connection (correct me of course), there was nothing > > fancy with isolation tests, yet. Not saying that this is useless for > > isolation tests, this would have its cases for assumptions where > > multiple GUCs need to be synced across multiple sessions, but it seems > > to me that we have two different cases in need of two different > > solutions. > > I didn't say we need to go for something more complete. Just that it's worth > thinking about.
FWIW, I have considered a few different approaches, but all of them were not only more work, they were fragile, and diffcult to prove correctness of. 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. The invoking client may be interested in just client-facing backends honoring the reload before moving on, so it would have to wait until all the other backends finish their current command and return to the main loop; but that may never happen, because one of the backends may be processing a long-running query. Or, for some reason, the the caller may be interested in only the autovacuum proccesses honoring its reload request. So I thought about creating _classes_ of backends: client-facing, other always-on children of Postmaster, BGWorkers, etc. But that just makes the problem more difficult to solve. I hadn't considered the possibilty of deadlocks that Tom raised, so that's another downside of the other approaches. 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. It sure is worth solving the case where a backend waits for another backed(s) to process the conf files, but it will have to be a separate solution, becuase it's much more difficult to get it right. Best regards, Gurjeet http://Gurje.et