MIME-Version: 1.0
References: <20220209231426.yngtrhioymltdblx@alap3.anarazel.de>
 <1521416.1644451001@sss.pgh.pa.us> <20220210003336.qi7voj352cpiymms@alap3.anarazel.de>
In-Reply-To: <20220210003336.qi7voj352cpiymms@alap3.anarazel.de>
From: David Rowley <dgrowleyml@gmail.com>
Date: Thu, 7 Dec 2023 19:33:13 +1300
Message-ID: <CAApHDvrcWM9ize8oLujumwaEmTTcmQWXtHe4C-TiD1Dx2jAtFA@mail.gmail.com>
Subject: Re: catalog access with reset GUCs during parallel worker startup
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, 
	Robert Haas <robertmhaas@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAApHDvrcWM9ize8oLujumwaEmTTcmQWXtHe4C-TiD1Dx2jAtFA%40mail.gmail.com>
Precedence: bulk

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