Message-ID: <73daabb7-9fc7-fb7a-5e06-a968c611b032@enterprisedb.com>
Date: Tue, 25 Jan 2022 15:21:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.5.0
Subject: Re: fix crash with Python 3.11
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
References: <3375ffd8-d71c-2565-e348-a597d6e739e3@enterprisedb.com>
 <3890110.1642373624@sss.pgh.pa.us>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <3890110.1642373624@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/73daabb7-9fc7-fb7a-5e06-a968c611b032%40enterprisedb.com>
Precedence: bulk

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.)
> 
> 2. In the PG_CATCH block, after collecting the error data do
> 	AbortOutOfAnyTransaction();
> 	StartTransactionCommand();
> which gets us into a good state with no active subtransactions.
> 
> I'm not sure that those two are the best choices of xact.c
> entry points, but there's precedent for that in autovacuum.c
> among other places.

AFAICT, AbortOutOfAnyTransaction() also aborts subtransactions, so why 
do you suggest the separate handling of subtransactions?