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
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.
Markus Wanner 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
> sit
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
Markus Wanner 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
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.
Actua
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 alread
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_comm
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 proble
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
Peter Eisentraut 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 wou
On 25.01.22 16:54, Tom Lane wrote:
Peter Eisentraut 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 "ca
Peter Eisentraut 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 su
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
Peter Eisentraut 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
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
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
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
18 matches
Mail list logo
