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
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 |