Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function
От | Jeff Ross |
---|---|
Тема | Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function |
Дата | |
Msg-id | 45d75f81-0be1-4990-97a7-5b4fa0e37c65@openvistas.net обсуждение исходный текст |
Ответ на | Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: After 10 -> 15 upgrade getting "cannot commit while a portal is pinned" on one python function
|
Список | 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
В списке pgsql-general по дате отправления: