Re: fix crash with Python 3.11

This patch needs another close pass and possibly some refactoring to
avoid copy-and-paste, but I'm putting this out here, since people are
already testing with Python 3.11 and will surely run into this problem.

The way plpy.commit() and plpy.rollback() handle errors is not ideal.
They end up just longjmping back to the main loop, without telling the
Python interpreter about it. This hasn't been a problem so far,
apparently, but with Python 3.11-to-be, this appears to cause corruption
in the state of the Python interpreter. This is readily reproducible
and will cause crashes in the plpython_transaction test.

The fix is that we need to catch the PostgreSQL error and turn it into a
Python exception, like we do for other places where plpy.* methods call
into PostgreSQL internals.

On Wed, 2021-12-22 at 09:24 +0100, Peter Eisentraut wrote:
> The fix is that we need to catch the PostgreSQL error and turn it into a
> Python exception, like we do for other places where plpy.* methods call
> into PostgreSQL internals.

Tested on Ubuntu 20.04, with 3.11.0a3 (built by hand) and 3.8.10 (from
the repositories). The tests pass, so LGTM. I agree that tidying up
some of the code duplication would be nice.

Thanks,
--Jacob

Hello,

I run vcregeress plcheck on Windows Server 2016 with python 3.11.0a3 and python 3.9.7 which are installed using installer.
All tests are passed. I'm not familiar with PL/Python but I think it's good.

regards, sho kato

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> The way plpy.commit() and plpy.rollback() handle errors is not ideal.
> They end up just longjmping back to the main loop, without telling the
> Python interpreter about it. This hasn't been a problem so far,
> apparently, but with Python 3.11-to-be, this appears to cause corruption
> in the state of the Python interpreter. This is readily reproducible
> and will cause crashes in the plpython_transaction test.
> The fix is that we need to catch the PostgreSQL error and turn it into a
> Python exception, like we do for other places where plpy.* methods call
> into PostgreSQL internals.

I agree that the existing code is broken and works only accidentally,
but I fear this patch does little to improve matters. In particular,
it returns control to Python without having done anything to clean
up the now-invalid state of the transaction system. (That is,
there's nothing analogous to PLy_spi_subtransaction_abort's
RollbackAndReleaseCurrentSubTransaction call in these new PG_CATCH
blocks). The existing test cases apparently fail to trip over that
because Python just throws the exception again, but what if someone
writes a plpython function that catches the exception and then tries
to perform new SPI actions?

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. (autovacuum seems to think that blocking
interrupts is a good idea too.)

regards, tom lane

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?

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

On 25.01.22 16:54, Tom Lane wrote:
> 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.

I've been struggling to make progress on this. First, throwing the
Python exception suggested in #1 above would require a significant
amount of new code. (We have code to create an exception out of
ErrorData, but no code to make one up from nothing.) This would need
further thought on how to arrange the code sensibly. Second, calling
AbortOutOfAnyTransaction() appears to clean up so much stuff that even
the data needed for error handling in PL/Python is wiped out. The
symptoms are various crashes on pointers now valued 0x7f7f7f... You fix
one, you get the next one. So more analysis would be required there, too.

One way to way to address the first problem is to not handle the "cannot
commit while a subtransaction is active" and similar cases manually but
let _SPI_commit() throw the error and then check in PL/Python for the
error code ERRCODE_INVALID_TRANSACTION_TERMINATION. (The code in
_SPI_commit() is there after all explicitly for PLs, so if we're not
using it, then we're doing it wrong.) And then only call
AbortOutOfAnyTransaction() (or whatever) if it's a different code, which
would mean something in the actual committing went wrong.

But in any case, for either implementation it seems then you'd get
different error behavior from .commit and .rollback calls depending on
the specific error, which seems weird.

Altogether, maybe the response to

> The existing test cases apparently fail to trip over that
> because Python just throws the exception again, but what if someone
> writes a plpython function that catches the exception and then tries
> to perform new SPI actions?

perhaps should be, don't do that then?

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> I've been struggling to make progress on this. First, throwing the
> Python exception suggested in #1 above would require a significant
> amount of new code. (We have code to create an exception out of
> ErrorData, but no code to make one up from nothing.) This would need
> further thought on how to arrange the code sensibly. Second, calling
> AbortOutOfAnyTransaction() appears to clean up so much stuff that even
> the data needed for error handling in PL/Python is wiped out.

Yeah, it's messy.

> One way to way to address the first problem is to not handle the "cannot
> commit while a subtransaction is active" and similar cases manually but
> let _SPI_commit() throw the error and then check in PL/Python for the
> error code ERRCODE_INVALID_TRANSACTION_TERMINATION. (The code in
> _SPI_commit() is there after all explicitly for PLs, so if we're not
> using it, then we're doing it wrong.)

TBH, I've thought from day one that _SPI_commit and friends are unusably
simplistic, precisely because they throw all this error-recovery
complexity onto the caller, and provide no tools to handle it without
dropping down to a lower level of abstraction.

> But in any case, for either implementation it seems then you'd get
> different error behavior from .commit and .rollback calls depending on
> the specific error, which seems weird.

Well, I think we *have to* do that. The INVALID_TRANSACTION_TERMINATION
errors mean that we're in some kind of atomic execution context that
we mustn't destroy. Other errors mean that the commit failed, and that
has to be cleaned up somehow.

(Note: there is also an INVALID_TRANSACTION_TERMINATION error in
HoldPinnedPortals, which is now seeming like a mistake to me; we should
change that to some other errcode, perhaps. There are no others
besides _SPI_commit/_SPI_rollback.)

> Altogether, maybe the response to

>>> The existing test cases apparently fail to trip over that
>>> because Python just throws the exception again, but what if someone
>>> writes a plpython function that catches the exception and then tries
>>> to perform new SPI actions?

> perhaps should be, don't do that then?

That seems far south of acceptable to me. I experimented with the
attached script, which in HEAD just results in aborting the Python
script -- not good, but at least the general state of the session
is okay. With your patch, I get

INFO: sqlstate: 23503
INFO: after exception
WARNING: buffer refcount leak: [8760] (rel=base/16384/38401, blockNum=0, flags=0x93800000, refcount=1 1)
WARNING: relcache reference leak: relation "testfk" not closed
WARNING: relcache reference leak: relation "testpk" not closed
WARNING: TupleDesc reference leak: TupleDesc 0x7f3a12e0de80 (38403,-1) still referenced
WARNING: snapshot 0x1cba150 still active
DO
f1
----
0
1
(2 rows)

So aside from all the internal problems, we've actually managed to commit
an invalid database state. I do not find that OK.

I think that maybe we could get somewhere by having _SPI_commit/rollback
work like this:

1. Throw the INVALID_TRANSACTION_TERMINATION errors if appropriate.
The caller can catch those and proceed if desired, knowing that the
transaction system is in the same state it was.

2. Use a PG_TRY block to do the commit or rollback. On error,
roll back (knowing that we are not in a subtransaction) and then
re-throw the error.

If the caller catches an error other than INVALID_TRANSACTION_TERMINATION,
it can proceed, but it's still on the hook to do SPI_start_transaction
before it attempts any new database access (just as it would be if
there had not been an error).

We could provide a simplified API in which SPI_start_transaction is
automatically included for either success or failure, so that the caller
doesn't have the delayed-cleanup responsibility. I'm not actually sure
that there is any situation where that couldn't be done, but putting it
into the existing functions would be a API break (... unless we turn
SPI_start_transaction into a no-op, which might be OK?) Basically this'd
be making the behavior of SPI_commit_and_chain the norm, except you'd
have the option of reverting to default transaction settings instead
of the previous ones.

So basically where we'd end up is that plpython would do about what
you show in your patch, but then there's additional work needed in
spi.c so that we're not leaving the rest of the system in a bad state.

regards, tom lane

I wrote:
> We could provide a simplified API in which SPI_start_transaction is
> automatically included for either success or failure, so that the caller
> doesn't have the delayed-cleanup responsibility. I'm not actually sure
> that there is any situation where that couldn't be done, but putting it
> into the existing functions would be a API break (... unless we turn
> SPI_start_transaction into a no-op, which might be OK?) Basically this'd
> be making the behavior of SPI_commit_and_chain the norm, except you'd
> have the option of reverting to default transaction settings instead
> of the previous ones.
> So basically where we'd end up is that plpython would do about what
> you show in your patch, but then there's additional work needed in
> spi.c so that we're not leaving the rest of the system in a bad state.

Here's a draft patch that works that way. I haven't tested it against
Python 3.11, but it handles the case I showed upthread (now incorporated
as a regression test), as well as Alexander's repeat-till-stack-overflow
problem. The one thing I found that I wasn't expecting is that
AtEOXact_SPI is quite a few bricks shy of a load: it doesn't handle
cases where some atomic contexts are atop an internal_xact one. That
happens in the new test case because the error is thrown from RI
triggers that themselves use SPI.

This is draft mainly in that

* I didn't touch spi.sgml yet.

* It might be a good idea to add parallel test cases for the other PLs.

* I'm not satisfied with using static storage for
SaveTransactionCharacteristics/RestoreTransactionCharacteristics.
It'd be better for them to use a struct allocated locally in the caller.
That would be a simple enough change, but also an API break; on the
other hand, I really doubt anything outside core code is calling those.
Anyone object to changing them?

I'm not sure how to proceed with this. It's kind of a large change
to be putting into back branches, but our hands will be forced once
Python 3.11 is out. Maybe put it in HEAD now, and plan to back-patch
in a few months?

regards, tom lane

I wrote:
> * It might be a good idea to add parallel test cases for the other PLs.

As I suspected, plperl and pltcl show exactly the same problems
when trapping a failure at commit, reinforcing my opinion that this
is a SPI bug that needs to be fixed in SPI. (plpgsql is not subject
to this problem, because its only mechanism for trapping errors is
a BEGIN block, ie a subtransaction, so it won't get to the interesting
part.) They do have logic to catch the thrown error, though, so no
additional fix is needed in either once we fix the core code.

v2 attached adds those test cases.

regards, tom lane

I wrote:
> * I'm not satisfied with using static storage for
> SaveTransactionCharacteristics/RestoreTransactionCharacteristics.

Looking closer at this, I was not too amused to discover that of the three
existing SaveTransactionCharacteristics calls, two already conflict with
each other: _SPI_commit calls SaveTransactionCharacteristics and then
calls CommitTransactionCommand, which again calls
SaveTransactionCharacteristics, overwriting the static storage.
I *think* there's no live bug there, because the state probably wouldn't
have changed in between; but considering we run arbitrary user-defined
code between those two points I sure wouldn't bet on it.

0001 attached is the same code patch as before, but now with spi.sgml
updates; 0002 changes the API for Save/RestoreTransactionCharacteristics.
If anyone's really worried about backpatching 0002, we could perhaps
get away with doing that only in HEAD.

I found in 0002 that I had to make CommitTransactionCommand call
SaveTransactionCharacteristics unconditionally, else I got warnings
about possibly-uninitialized local variables. It's cheap enough
that I'm not too fussed about that. I don't get any warnings from
the similar code in spi.c, probably because those functions can't
be inlined there.

regards, tom lane

Is it time yet to back-patch 2e517818f ("Fix SPI's handling of errors
during transaction commit")? We know we're going to have to do it
before Python 3.11 ships, and it's been stable in HEAD for 3.5 months
now. Also, the Fedora guys absorbed the patch a couple weeks ago [1]
because they're already using 3.11 in rawhide, and I've not heard
complaints from that direction.

My inclination at this point is to not back-patch the second change
12d768e70 ("Don't use static storage for SaveTransactionCharacteristics").
It's not clear that the benefit would be worth even a small risk of
somebody being unhappy about the API break.

regards, tom lane

[1] /message-id/flat/CA%2BHKMWMY_e2otmTJDjKUAvC8Urh4rzSWOPZ%3DfszU5brkBP97ng%40mail.gmail.com

On 6/21/22 18:33, Tom Lane wrote:
> My inclination at this point is to not back-patch the second change
> 12d768e70 ("Don't use static storage for SaveTransactionCharacteristics").
> It's not clear that the benefit would be worth even a small risk of
> somebody being unhappy about the API break.

Actually, the backport of 2e517818f ("Fix SPI's handling of errors")
already broke the API for code using SPICleanup, as that function had
been removed. Granted, it's not documented, but still exported.

I propose to re-introduce a no-op placeholder similar to what we have
for SPI_start_transaction, somewhat like the attached patch.

Regards

Markus

Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> writes:
> Actually, the backport of 2e517818f ("Fix SPI's handling of errors")
> already broke the API for code using SPICleanup, as that function had
> been removed. Granted, it's not documented, but still exported.

Under what circumstances would it be OK for outside code to call
SPICleanup?

regards, tom lane

On 6/23/22 15:34, Tom Lane wrote:
> Under what circumstances would it be OK for outside code to call
> SPICleanup?

For the same reasons previous Postgres versions called SPICleanup: from
a sigsetjmp handler that duplicates most of what Postgres does in such a
situation.

However, I think that's the wrong question to ask for a stable branch.
Postgres did export this function in previous versions. Removing it
altogether constitutes an API change and makes extensions that link to
it fail to even load, which is a bad way to fail after a patch version
upgrade. Even if its original use was not sound in the first place.

Ofc my proposed patch is not meant for master, only for stable branches.

Best Regards

Markus

Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> writes:
> On 6/23/22 15:34, Tom Lane wrote:
>> Under what circumstances would it be OK for outside code to call
>> SPICleanup?

> For the same reasons previous Postgres versions called SPICleanup: from
> a sigsetjmp handler that duplicates most of what Postgres does in such a
> situation.

Does such code exist? I don't see any other calls in Debian code search,
and I find it hard to believe that anyone would think such a thing is
maintainable.

regards, tom lane

On 6/24/22 00:54, Tom Lane wrote:
> Does such code exist? I don't see any other calls in Debian code search,
> and I find it hard to believe that anyone would think such a thing is
> maintainable.

Such a thing does exist within PGLogical and BDR, yes.

Thanks for your concern about maintainability. So far, that part was not
posing any trouble. Looking at e.g. postgres.c, the sigsetjmp handler
there didn't change all that much in recent years. Much of the code
there is from around 2004 written by you.

However, that shouldn't be your concern at all. Postgres refusing to
start after a minor upgrade probably should, especially when it's due to
an API change in a stable branch.

Regards

Markus

On 23.06.22 09:41, Markus Wanner wrote:
>
> On 6/21/22 18:33, Tom Lane wrote:
>> My inclination at this point is to not back-patch the second change
>> 12d768e70 ("Don't use static storage for
>> SaveTransactionCharacteristics").
>> It's not clear that the benefit would be worth even a small risk of
>> somebody being unhappy about the API break.
>
> Actually, the backport of 2e517818f ("Fix SPI's handling of errors")
> already broke the API for code using SPICleanup, as that function had
> been removed. Granted, it's not documented, but still exported.
>
> I propose to re-introduce a no-op placeholder similar to what we have
> for SPI_start_transaction, somewhat like the attached patch.

I have applied your patch to branches 11 through 14.