Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, andrewbille(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Date: 2022-03-09 02:26:42
Message-ID: CAD21AoD5MsR_GR5iipc8TnGa3grzQbPLpwZcSn8Fq2dZbar_6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Feb 16, 2022 at 1:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> writes:
> > It seems that we need another flag or a dedicated treatment for
> > transaction property GUCs. It effectively cannot change them within
> > the transaction regardless of SET, RESET, and RESET ALL, so I think we
> > can make it no-op (possibly with a notice).
>
> Yeah, I was considering that too. A new GUC_NO_RESET flag would be
> cheaper than running the check hooks during RESET, and probably
> safer too. On the other hand, we would lose the property that
> you can reset these settings as long as you've not yet taken a
> snapshot. I wonder whether there is any code out there that
> depends on that ...

Indeed. I guess that it's relatively common that the transaction
isolation level is set after BEGIN TRANSACTION but I've not heard that
it's reset after BEGIN TRANSACTION with setting non-default
transaction isolation level.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Sergey Mirvoda 2022-03-09 12:20:23 2000 times performance drop after pg14 upgrade when JIT = 1
Previous Message Tom Lane 2022-03-08 21:19:39 Re: Bug plperl.c