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

On Wed, Mar 23, 2022 at 5:48 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Tue, Mar 15, 2022 at 3:59 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Attached an updated patch. I kept the name GUC_NO_RESET but I'll
change it if we find a better name for it.

Regards,

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