Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Justin Pryzby <pryzby@telsasoft.com>,
Dmitry Koval <d.koval@postgrespro.ru>,
Dilip Kumar <dilipbalaut@gmail.com>, andrewbille@gmail.com,
pgsql-bugs@lists.postgresql.org,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-09-24T20:57:51Z
Lists: pgsql-bugs
Attachments
- v6-0001-Introduce-GUC_NO_RESET-flag.patch (text/x-diff) patch v6-0001
- v6-0002-Reorganize-GUC_XXX-flag-values.patch (text/x-diff) patch v6-0002
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> I've attached patches.
Per the cfbot, this incorrectly updates the plpgsql_transaction
test. Here's an updated version that fixes that.
The proposed error message for the GUC_ACTION_SAVE case,
errmsg("parameter \"%s\" cannot be set temporarily or in functions locally",
does not seem like very good English to me. In the attached I changed
it to
errmsg("parameter \"%s\" cannot be set temporarily or locally in functions",
but that isn't great either: it seems redundant and confusing.
I think we could just make it
errmsg("parameter \"%s\" cannot be set locally in functions",
because that's really the only case users should ever see.
Other than the message-wording issue, I think v6-0001 is OK.
> I did the reorganization of GUC flags in a separate patch (0002 patch)
> since it's not relevant with the new flag GUC_NO_RESET.
0002 seems quite invasive and hard to review compared to what it
accomplishes. I think we should just keep the flags in the same
order, stick in GUC_NO_RESET in front of GUC_NO_RESET_ALL, and
renumber the flag values as needed. I did not change 0002 below,
though.
regards, tom lane
Commits
-
Renumber GUC flags for a bit more sanity.
- 7ac918ada003 16.0 landed
-
Introduce GUC_NO_RESET flag.
- 385366426511 16.0 landed