Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Date
Msg-id 212334.1647284377@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-bugs
After thinking about this some more, it seems like there is a related
problem with GUC save/restore actions.  Consider

regression=# create function foo() returns int language sql as 'select 1'
regression-# set transaction_read_only = 1;
CREATE FUNCTION
regression=# begin;
BEGIN
regression=*# select foo();
 foo 
-----
   1
(1 row)

regression=*# show transaction_read_only;
 transaction_read_only 
-----------------------
 off
(1 row)

transaction_read_only was set while we executed foo(), but now it's
off again.  I've not tried to weaponize this behavior, but if we
have any optimizations that depend on transaction_read_only, this
would probably break them.  (SERIALIZABLE mode looks like a likely
candidate for problems.)

So it seems like we also need to forbid save/restore for these
settings, which probably means rejecting action==GUC_ACTION_SAVE
as well as value==NULL.  That makes NO_RESET something of a misnomer,
but I don't have an idea for a better name.

            regards, tom lane



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17438: Logical replication hangs on master after huge DB load
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum