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 transaction, which signals to several GUC hooks that they can do catalog access 2) RestoreGUCState() resets all non-skipped GUC values to their "boot_val" first and then in another pass sets all GUCs that were non-default in the leader. This e.g. can lead to parallel worker startup using the wrong fsync or wal_sync_method value when catalog accesses trigger WAL writes. Luckily PGC_POSTMASTER GUCs are skipped, otherwise this'd be kinda bad. But it still doesn't seem good. 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? Greetings, Andres Freund