Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Dmitry Koval <d.koval@postgrespro.ru>
Cc: andrewbille@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-02-04T08:48:41Z
Lists: pgsql-bugs
Attachments
- call_check_hook_on_reset.patch (application/octet-stream) patch
On Sat, Jan 29, 2022 at 12:26 AM Dmitry Koval <d.koval@postgrespro.ru> wrote: > > Hi, > > Additional information. Query > "RESET transaction_isolation;" > in previous message can be replaced to synonym > "SET transaction_isolation=DEFAULT;" > (error will be the same). > > I attached file with simple fix for branch "master". > > I not sure that need to use a separate block of code for the > "transaction_isolation" GUC-variable. But this is a special variable > and there are several places in the code with handling of this variable. IIUC this problem comes from the fact that RESET command doesn't call check_hook of GUC parameters. Therefore, all GUC parameters that don’t expect to be changed after something operations are affected. For example, in addition to transaction_isolation, we don’t support changing transaction_read_only and default_transaction_deferrable after the first snapshot is taken. Also, we don’t support changing temp_buffers after accessing any temp tables in the session. But RESET’ing these parameters bypasses the check. Considering these facts, I think it’s better to call check_hook even in resetting cases. I've attached a patch (with regression tests) for discussion. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
Commits
-
Renumber GUC flags for a bit more sanity.
- 7ac918ada003 16.0 landed
-
Introduce GUC_NO_RESET flag.
- 385366426511 16.0 landed