From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)heterodb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/Python - lifetime of variables? |
Date: | 2020-02-19 01:39:16 |
Message-ID: | CAMsr+YFgxSurBGWDuTgCK_P0j_s+4t2VF6--zbhJ+FNxJY=-1Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 19 Feb 2020 at 09:12, Kohei KaiGai <kaigai(at)heterodb(dot)com> wrote:
> I noticed that variables in PL/Python are not released at the end of procedure.
> Does it expected behavior?
PL/Python vars are freed when the interpreter instance is freed and
their refcounts reach zero.
I believe we use one subinterpreter for the lifetime of the backend
session. It might be worth checking whether we do an eager refcount
check and sweep when a procedure finishes.
But in general, I suggest that relying on object
finalizers/destructors to accomplish side effects visible outside the
procedure is bad development practice. Instead, use a "with" block, or
a try/finally block, and do explicit cleanup for external resources.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-02-19 02:14:24 | Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() |
Previous Message | Peter Geoghegan | 2020-02-19 01:37:40 | Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() |