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
|
Список | 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 по дате отправления: