On Thu, 10 Feb 2022 at 13:33, Andres Freund <and...@anarazel.de> wrote: > Postmaster's GUC state will already be loaded via read_nondefault_variables(), > much earlier in startup. Well before bgworkers get control and before > transaction environment is up. > > Setting a watchpoint on enableFsync, in a parallel worker where postmaster > runs with enableFsync=off, shows the following:
The following comment in RestoreGUCState() starting with "since the leader's" seems to indicate this step is required. > * but already have their default values. Thus, this ends up being the > * same test that SerializeGUCState uses, even though the sets of > * variables involved may well be different since the leader's set of > * variables-not-at-default-values can differ from the set that are > * not-default in this freshly started worker. I'm just not quite clear on which cases this could be. Looking at InitializeOneGUCOption(), the newval comes from conf->boot_val, which, for built-in GUCs just comes from the ConfigureNames* table in guc_tables.c. Perhaps there could be variances in values that are passed during the call to DefineCustom*Variable between the leader and the worker in some extension's code. David
