pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Allow parallel workers to cope with a newly-created session user
8+ messages / 1 participants
[nested] [flat]
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f5f30c22ed69fb37b896c4d4546b2ab823c3fd61
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/68855c03878c0c90227e24533ca40127da3578cd
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/97380d4803d1f9188a1436c6fe7ecd7db285c55c
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/216201027d90e99a0a2b2d2efba85dc0aac94c62
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/849326e49a5dd56941eb8fb4699130c301bff303
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/48536305370acd75c6264fcefec7fae7af8c5440
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-07-31 22:54 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-07-31 22:54 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/5887dd4894db5ac1c6411615160555ac6e57e49b
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
* pgsql: Allow parallel workers to cope with a newly-created session user
@ 2024-08-06 16:37 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2024-08-06 16:37 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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.
This un-reverts commit f5f30c22e. The original plan was to back-patch
that, but the fact that 0ae5b763e proved to be a pre-requisite shows
that the subtle API change for GUC hooks might actually break some of
them. The problem we're trying to fix seems not worth taking such a
risk for in stable branches.
Per bug #18545 from Andrey Rachitskiy.
Discussion: https://postgr.es/m/18545-feba138862f19aaa@postgresql.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/6e086fa2e771ad4c0b2d3cca4e2de209a92c719b
Modified Files
--------------
src/backend/access/transam/parallel.c | 12 ++++++++----
src/backend/commands/variable.c | 10 ++++++++--
src/test/regress/expected/select_parallel.out | 18 ++++++++++++++++++
src/test/regress/sql/select_parallel.sql | 9 +++++++++
4 files changed, 43 insertions(+), 6 deletions(-)
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2024-08-06 16:37 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-07-31 22:54 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
2024-08-06 16:37 pgsql: Allow parallel workers to cope with a newly-created session user Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox