From: Tom Lane <tgl@sss.pgh.pa.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Dmitry Koval <d.koval@postgrespro.ru>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: 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
Date: Mon, 14 Feb 2022 00:39:28 -0500
Message-ID: <2778050.1644817168@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, sawada.mshk@gmail.com, d.koval@postgrespro.ru, dilipbalaut@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
In-Reply-To: <2778050.1644817168@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox