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

On Tue, Mar 15, 2022 at 3:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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)

Good catch.

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

Yes, it seems we need that change too. I'll update the patch.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/