Re: catalog access with reset GUCs during parallel worker startup

On Thu, 10 Feb 2022 at 13:33, Andres Freund <andres(at)anarazel(dot)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