From: Tom Lane <tgl@sss.pgh.pa.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
cc: Dmitry Koval <d.koval@postgrespro.ru>,
 Dilip Kumar <dilipbalaut@gmail.com>,
        andrewbille@gmail.com,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable
 transaction causes Assert at the transaction end
In-reply-to: <2733419.1644789029@sss.pgh.pa.us>
References: <17385-9ee529fb091f0ce5@postgresql.org>
 <b22395d2-d432-f211-0bed-1f466df75152@postgrespro.ru>
 <CAD21AoCkwsb_Hz6JYbG0X8Jf_VEMheiib0FXpR2kc3UATVCPNQ@mail.gmail.com>
 <CAFiTN-sYZ0Cuyeygp7z8xfoFPhqTAbtnV+k2W9OHp8s0xus5vw@mail.gmail.com>
 <f97d670d-2b03-9d47-6b64-09e6ed2f4d84@postgrespro.ru>
 <CAFiTN-sCr6mYg8A_BBiRz0N68M9QY3uoBWHhbPgHDM-goLJGwg@mail.gmail.com>
 <6e31c4ef-de9a-960b-1a21-e3b6ff0fa9c2@postgrespro.ru>
 <CAD21AoB8acvjt+52iwffAi7Ary_fyMD70X371hVX1JULrc-meQ@mail.gmail.com>
 <2733419.1644789029@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 13 Feb 2022 16:50:29 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2735165.1644790175.1@sss.pgh.pa.us>
Date: Sun, 13 Feb 2022 17:09:35 -0500
Message-ID: <2735166.1644790175@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2735166.1644790175%40sss.pgh.pa.us>
Precedence: bulk

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.

			regards, tom lane