Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: sawada(dot)mshk(at)gmail(dot)com, d(dot)koval(at)postgrespro(dot)ru, dilipbalaut(at)gmail(dot)com, andrewbille(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Date: 2022-03-14 18:59:37
Message-ID: 212334.1647284377@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2022-03-14 19:05:14 Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
Previous Message PG Bug reporting form 2022-03-14 17:30:25 BUG #17438: Logical replication hangs on master after huge DB load