From: | Jeff Ross <jross(at)openvistas(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function |
Date: | 2024-03-27 23:05:21 |
Message-ID: | 45d75f81-0be1-4990-97a7-5b4fa0e37c65@openvistas.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 3/27/24 15:44, Tom Lane wrote:
> Perhaps "pinned" in the error message means "open"?
> No, it means "pinned" ... but I see that plpython pins the portal
> underlying any PLyCursor object it creates. Most of our PLs do
> that too, to prevent a portal from disappearing under them (e.g.
> if you were to try to close the portal directly from SQL rather
> than via whatever mechanism the PL wants you to use).
>
>> I added a cursor.close() as the last line called in that function and it
>> works again.
> It looks to me like PLy_cursor_close does pretty much exactly the same
> cleanup as PLy_cursor_dealloc, including unpinning and closing the
> underlying portal. I'm far from a Python expert, but I suspect that
> the docs you quote intend to say "cursors are disposed of when Python
> garbage-collects them", and that the reason your code is failing is
> that there's still a reference to the PLyCursor somewhere after the
> plpython function exits, perhaps in a Python global variable.
>
> regards, tom lane
>
>
Thank you for your reply, as always, Tom!
Debugging at this level might well be over my paygrade ;-)
I just happy that the function works again, and that I was able to share
a solution to this apparently rare error with the community.
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2024-03-27 23:35:03 | Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function |
Previous Message | Tom Lane | 2024-03-27 21:44:37 | Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function |