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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Дата
Msg-id 212334.1647284377@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17438: Logical replication hangs on master after huge DB load
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum