Allow parallel workers to cope with a newly-created session user ID.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 31 Jul 2024 22:54:10 +0000 (18:54 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 31 Jul 2024 22:54:10 +0000 (18:54 -0400)
commitf5f30c22ed69fb37b896c4d4546b2ab823c3fd61
treec9e42ffc096404be7f008b9355e3634aa41c546e
parentbd15b7db489deadb2d9af7f21d16a6ed4a09465b
Allow parallel workers to cope with a newly-created session user ID.

Parallel workers failed after a sequence like
BEGIN;
CREATE USER foo;
SET SESSION AUTHORIZATION foo;
because check_session_authorization could not see the uncommitted
pg_authid row for "foo".  This is because we ran RestoreGUCState()
in a separate transaction using an ordinary just-created snapshot.
The same disease afflicts any other GUC that requires catalog lookups
and isn't forgiving about the lookups failing.

To fix, postpone RestoreGUCState() into the worker's main transaction
after we've set up a snapshot duplicating the leader's.  This affects
check_transaction_isolation and check_transaction_deferrable, which
think they should only run during transaction start.  Make them
act like check_transaction_read_only, which already knows it should
silently accept the value when InitializingParallelWorker.

Per bug #18545 from Andrey Rachitskiy.  Back-patch to all
supported branches, because this has been wrong for awhile.

Discussion: https://postgr.es/m/18545-feba138862f19aaa@postgresql.org
src/backend/access/transam/parallel.c
src/backend/commands/variable.c
src/test/regress/expected/select_parallel.out
src/test/regress/sql/select_parallel.sql