| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| 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-02-15 16:55:22 |
| Message-ID: | 3054063.1644944122@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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 ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2022-02-15 17:32:33 | BUG #17406: Segmentation fault on GiST index after 14.2 upgrade |
| Previous Message | Masahiko Sawada | 2022-02-15 16:47:56 | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |