Re: catalog access with reset GUCs during parallel worker startup

Hi,

On 2022-02-09 18:56:41 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Do we really need to reset GUCs to their boot value? Particularly for
> > PGC_SIGHUP variables I don't think we can do that if we want to do
> > RestoreGUCState() in a transaction. It'd obviously involve a bit more code,
> > but it seems entirely possible to just get rid of the reset phase?
>
> In an EXEC_BACKEND build, they're going to start out with those
> values anyway. If you're not happy about the consequences,
> "skipping the reset" is not the way to improve matters.

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:

Old value = true
New value = false
set_config_option (name=0x7f42bd9ec110 "fsync", value=0x7f42bd9ec000 "false", context=PGC_POSTMASTER, source=PGC_S_ARGV, action=GUC_ACTION_SET,
changeVal=true, elevel=21, is_reload=true) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:7760
7760 set_extra_field(&conf->gen, &conf->gen.extra,
(rr) bt
#0 set_config_option (name=0x7f42bd9ec110 "fsync", value=0x7f42bd9ec000 "false", context=PGC_POSTMASTER, source=PGC_S_ARGV, action=GUC_ACTION_SET,
changeVal=true, elevel=21, is_reload=true) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:7760
#1 0x00007f42bcd5f178 in read_nondefault_variables () at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:10635
#2 0x00007f42bca9ccd1 in SubPostmasterMain (argc=3, argv=0x7f42bd9c93c0) at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:5086
#3 0x00007f42bc98bcef in main (argc=3, argv=0x7f42bd9c93c0) at /home/andres/src/postgresql/src/backend/main/main.c:194

Old value = false
New value = true
InitializeOneGUCOption (gconf=0x7f42bd0a32c0 <ConfigureNamesBool+4320>) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:5900
5900 conf->gen.extra = conf->reset_extra = extra;
(rr) bt
#0 InitializeOneGUCOption (gconf=0x7f42bd0a32c0 <ConfigureNamesBool+4320>) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:5900
#1 0x00007f42bcd5ff95 in RestoreGUCState (gucstate=0x7f42bc4f1d00) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:11135
#2 0x00007f42bc720873 in ParallelWorkerMain (main_arg=545066472) at /home/andres/src/postgresql/src/backend/access/transam/parallel.c:1408
#3 0x00007f42bca884e5 in StartBackgroundWorker () at /home/andres/src/postgresql/src/backend/postmaster/bgworker.c:858
#4 0x00007f42bca9cfd1 in SubPostmasterMain (argc=3, argv=0x7f42bd9c93c0) at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:5230
#5 0x00007f42bc98bcef in main (argc=3, argv=0x7f42bd9c93c0) at /home/andres/src/postgresql/src/backend/main/main.c:194

Old value = true
New value = false
set_config_option (name=0x7f42bc4f1e04 "fsync", value=0x7f42bc4f1e0a "false", context=PGC_POSTMASTER, source=PGC_S_ARGV, action=GUC_ACTION_SET,
changeVal=true, elevel=21, is_reload=true) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:7760
7760 set_extra_field(&conf->gen, &conf->gen.extra,
(rr) bt
#0 set_config_option (name=0x7f42bc4f1e04 "fsync", value=0x7f42bc4f1e0a "false", context=PGC_POSTMASTER, source=PGC_S_ARGV, action=GUC_ACTION_SET,
changeVal=true, elevel=21, is_reload=true) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:7760
#1 0x00007f42bcd600fc in RestoreGUCState (gucstate=0x7f42bc4f1d00) at /home/andres/src/postgresql/src/backend/utils/misc/guc.c:11172
#2 0x00007f42bc720873 in ParallelWorkerMain (main_arg=545066472) at /home/andres/src/postgresql/src/backend/access/transam/parallel.c:1408
#3 0x00007f42bca884e5 in StartBackgroundWorker () at /home/andres/src/postgresql/src/backend/postmaster/bgworker.c:858
#4 0x00007f42bca9cfd1 in SubPostmasterMain (argc=3, argv=0x7f42bd9c93c0) at /home/andres/src/postgresql/src/backend/postmaster/postmaster.c:5230
#5 0x00007f42bc98bcef in main (argc=3, argv=0x7f42bd9c93c0) at /home/andres/src/postgresql/src/backend/main/main.c:194

> Can we arrange to absorb the leader's values before starting the
> worker's transaction, instead of inside it?

I assume Robert did it this way for a reason? It'd not be surprising if there
were a bunch of extensions assuming its safe to do catalog accesses if
IsUnderPostmaster or such :(

Greetings,

Andres Freund