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

On Mon, Feb 14, 2022 at 7:09 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Hmm, here's a related anomaly:
>
> regression=# BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> BEGIN
> regression=*# savepoint foo;
> SAVEPOINT
> regression=*# RESET transaction_isolation;
> RESET
> regression=*# select 1;
>  ?column?
> ----------
>         1
> (1 row)
>
> regression=*# show transaction_isolation;
>  transaction_isolation
> -----------------------
>  read committed
> (1 row)
>
> regression=*# rollback to foo;
> ROLLBACK
> regression=*# show transaction_isolation;
>  transaction_isolation
> -----------------------
>  serializable
> (1 row)
>
> regression=*# commit;
> COMMIT
>
> I'm not sure why that didn't fail, but it seems like it should've:
> the commit-time isolation level is different from what we were
> using when we took the first snapshot.  (Maybe we discard the
> snapshot state when rolling back?  Not sure.)
>
> If we need to be sure that it's always okay to roll back a
> (sub)transaction, then that's an additional constraint on what's
> valid for GUCs to do.  Yet it'd be a really bad idea to run
> check_hooks during transaction rollback, so maybe there's little
> choice.

In this case, I think that "RESET transaction_isolation" should not be
allowed since we're already in a subtransaction. This is a result of
the fact that we bypass check_XactIsoLevel() in RESET.

Regards,

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