| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fix crash with Python 3.11 |
| Date: | 2022-01-25 15:54:44 |
| Message-ID: | 2255118.1643126084@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 16.01.22 23:53, Tom Lane wrote:
>> I think a possible fix is:
>>
>> 1. Before entering the PG_TRY block, check for active subtransaction(s)
>> and immediately throw a Python error if there is one. (This corresponds
>> to the existing errors "cannot commit while a subtransaction is active"
>> and "cannot roll back while a subtransaction is active". The point is
>> to reduce the number of system states we have to worry about below.)
> AFAICT, AbortOutOfAnyTransaction() also aborts subtransactions, so why
> do you suggest the separate handling of subtransactions?
We don't want these operations to be able to cancel subtransactions,
do we? The existing errors certainly suggest not.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2022-01-25 16:21:16 | Re: CREATEROLE and role ownership hierarchies |
| Previous Message | Masahiko Sawada | 2022-01-25 15:32:43 | Re: Skipping logical replication transactions on subscriber side |