| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, andrewbille(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Subject: | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
| Date: | 2022-09-26 04:07:50 |
| Message-ID: | 3268290.1664165270@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> Just to be sure about something here. The change of behavior with SET
> in the context of a PL makes this patch unsuitable for a backpatch,
> hence the plan is to apply this stuff only on HEAD, right?
Yeah, I think we concluded that back-patching might cause more
trouble than it's worth.
> + <entry><literal>NO_RESET</literal></entry>
> + <entry>Parameters with this flag do not support
> + <command>RESET</command> commands.
> + </entry>
> As per the issue with SET commands used with functions, this
> description does not completely reflect the reality.
It seems adequate enough to me ... do you have a suggestion?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-26 04:16:24 | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
| Previous Message | Michael Paquier | 2022-09-26 03:40:55 | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |