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: 
 <CAD21AoCxz=hU3c+6aB3OMNn+9NpH33WEMwOYmCOwh6EzOktYoA@mail.gmail.com>
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>
 <CAD21AoCxz=hU3c+6aB3OMNn+9NpH33WEMwOYmCOwh6EzOktYoA@mail.gmail.com>
Comments: In-reply-to Masahiko Sawada <sawada.mshk@gmail.com>
	message dated "Mon, 14 Feb 2022 14:13:27 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2778049.1644817168.1@sss.pgh.pa.us>
Date: Mon, 14 Feb 2022 00:39:28 -0500
Message-ID: <2778050.1644817168@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2778050.1644817168%40sss.pgh.pa.us>
Precedence: bulk

Masahiko Sawada <sawada.mshk@gmail.com> writes:
> On Mon, Feb 14, 2022 at 6:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It seems like a GUC might have an old value that we couldn't necessarily
>> RESET to, without also wanting to exempt it from RESET ALL.  However,
>> if it isn't exempt, yet the check_hook fails, what shall we do then?
>> Is throwing an error the best thing, or should we silently leave the
>> variable alone?  I think a lot of people would be unhappy if RESET ALL
>> / DISCARD ALL had failure conditions of this sort.  Should we document
>> that GUCs having state-dependent restrictions on their values had
>> better be marked GUC_NO_RESET_ALL?  If so, can we enforce that?

> Why do RESET ALL and RESET work differently with respect to resetting
> one GUC in the first place? IOW why GUC_NO_RESET_ALL works only in
> RESET ALL? It seems to me that RESET ALL is a command to do RESET
> every single GUC, so if a GUC is exempt from RESET ALL it should be
> exempt also from RESET.

I toyed with that idea for awhile too, but looking through the current
set of GUC_NO_RESET_ALL variables dissuaded me from it.  The
transaction-property GUCs need this behavior or something like it,
but the rest don't.  In particular, I fear that turning RESET ROLE
into a no-op would create security bugs for applications that
expect the current behavior.

Having said that, it does seem like GUC_NO_RESET_ALL is pretty
intellectually-inconsistent by definition.  I'm just not sure that
we can redefine our way out of that at this late date.

			regards, tom lane