Introduce GUC_NO_RESET flag.
Previously, the transaction-property GUCs such as transaction_isolation
could be reset after starting a transaction, because we marked them
as GUC_NO_RESET_ALL but still allowed a targeted RESET. That leads to
assertion failures or worse, because those properties aren't supposed
to change after we've acquired a transaction snapshot.
There are some NO_RESET_ALL variables for which RESET is okay, so
we can't just redefine the semantics of that flag. Instead introduce
a separate GUC_NO_RESET flag. Mark "seed", as well as the transaction
property GUCs, as GUC_NO_RESET.
We have to disallow GUC_ACTION_SAVE as well as straight RESET, because
otherwise a function having a "SET transaction_isolation" clause can
still break things: the end-of-function restore action is equivalent
to a RESET.
No back-patch, as it's conceivable that someone is doing something
this patch will forbid (like resetting one of these GUCs at transaction
start, or "CREATE FUNCTION ... SET transaction_read_only = 1") and not
running into problems with it today. Given how long we've had this
issue and not noticed, the side effects in non-assert builds can't be
too serious.
Per bug #17385 from Andrew Bille.
Masahiko Sawada
Discussion: https://postgr.es/m/17385-9ee529fb091f0ce5@postgresql.org
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/385366426511399a91da327c0f04765bbcfd5322
Modified Files
--------------
doc/src/sgml/func.sgml | 6 ++++
src/backend/utils/misc/guc.c | 20 +++++++++++++
src/backend/utils/misc/guc_funcs.c | 7 ++---
src/backend/utils/misc/guc_tables.c | 8 ++---
src/include/utils/guc.h | 1 +
.../plpgsql/src/expected/plpgsql_transaction.out | 5 ++--
src/pl/plpgsql/src/sql/plpgsql_transaction.sql | 3 +-
src/test/regress/expected/guc.out | 9 ++++++
src/test/regress/expected/transactions.out | 34 ++++++++++++++++++++++
src/test/regress/sql/guc.sql | 5 ++++
src/test/regress/sql/transactions.sql | 18 ++++++++++++
11 files changed, 103 insertions(+), 13 deletions(-)
