PL/Python - lifetime of variables?

From: Kohei KaiGai <kaigai(at)heterodb(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: PL/Python - lifetime of variables?
Date: 2020-02-19 01:12:19
Message-ID: CAOP8fzYSHKUejQFs5NU90pJA-PN4FB39zyPFeu4BAPkMMhra-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I noticed that variables in PL/Python are not released at the end of procedure.
Does it expected behavior?

See this example below:
https://github.com/heterodb/pg-strom/blob/master/test/input/arrow_python.source#L53

This PL/Python function maps a GPU buffer as cupy.ndarray object by
cupy_strom.ipc_import()
at the L59. It shall be stored in X. I have expected that X shall be
released at end of the
procedure invocation, but not happen.

The object X internally hold IpcMemory class,
https://github.com/heterodb/pg-strom/blob/master/python/cupy_strom.pyx
And, it has destructor routine that unmaps the above GPU buffer using CUDA API.
https://github.com/heterodb/pg-strom/blob/master/python/cupy_ipcmem.c#L242
Because of the restriction by CUDA API, we cannot map a certain GPU buffer twice
on the same process space. So, I noticed that the second invocation of
the PL/Python
procedure on the same session failed.
The L103 explicitly reset X, by X=0, to invoke the destructor manually.

I wonder whether it is an expected behavior, or oversight of something.

Best regards,
--
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai(at)heterodb(dot)com>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2020-02-19 01:35:41 Re: Internal key management system
Previous Message Thomas Munro 2020-02-19 00:44:42 Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()