Re: catalog access with reset GUCs during parallel worker startup

2023-12-06 Thread David Rowley
On Thu, 10 Feb 2022 at 13:33, Andres Freund 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

Re: catalog access with reset GUCs during parallel worker startup

2023-12-06 Thread David Rowley
On Wed, 23 Feb 2022 at 15:51, Andres Freund wrote: > The tests fail: > +ERROR: invalid value for parameter "session_authorization": "andres" > +CONTEXT: while setting parameter "session_authorization" to "andres" > +parallel worker > +while scanning relation "public.pvactst" > > but that's easil

Re: catalog access with reset GUCs during parallel worker startup

2022-02-22 Thread Andres Freund
Hi, I think we need to do something about this, because afaics this has data corruption risks, albeit with a narrow window. E.g. consider what happens if the value of wal_sync_method is reset to the boot value and one of the catalog accesses in GUC check hooks causes WAL writes (e.g. due to pruni

Re: catalog access with reset GUCs during parallel worker startup

2022-02-09 Thread Robert Haas
On Wed, Feb 9, 2022 at 7:33 PM Andres Freund wrote: > > 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

Re: catalog access with reset GUCs during parallel worker startup

2022-02-09 Thread Andres Freund
Hi, On 2022-02-09 18:56:41 -0500, Tom Lane wrote: > Andres Freund 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 cod

Re: catalog access with reset GUCs during parallel worker startup

2022-02-09 Thread Tom Lane
Andres Freund 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

catalog access with reset GUCs during parallel worker startup

2022-02-09 Thread Andres Freund
Hi, I noticed that during ParallelWorkerMain()->RestoreGUCState() we perform catalog accesses with GUCs being set to wrong values, specifically values that aren't what's in postgresql.conf, and that haven't been set in the leader. The reason for this is that 1) RestoreGUCState() is called in a t