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/
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 |