Re: pl/python long-lived allocations in datum->dict transformation

Поиск
Список
Период
Сортировка
От Jan Urbański
Тема Re: pl/python long-lived allocations in datum->dict transformation
Дата
Msg-id 4F418F31.1070204@wulczer.org
обсуждение исходный текст
Ответ на Re: pl/python long-lived allocations in datum->dict transformation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pl/python long-lived allocations in datum->dict transformation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 14/02/12 01:35, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer@wulczer.org> writes:
>> It's not very comfortable, but
>> I think PLyDict_FromTuple can be allowed to be non-reentrant.
>
> I think that's pretty short-sighted.  Even if it's safe today (which
> I am not 100% convinced of), there are plenty of foreseeable reasons
> why it might^Wwill break in the future.
>
>> OTOH if we want to make it reentrant, some more tinkering would be in order.
>
> I think that's in order.

Here are the results of the tinkering.

I came up with a stack of context structures that gets pushed when a
PL/Python starts being executed and popped when it returns. At first
they contained just a scratch memory context used by PLyDict_FromTuple.
Then under the premise of confirming the usefulness of introducing such
contexts I removed the global PLy_curr_procedure variable and changed
all users to get the current procedure from the context. It seems to
have worked, so the total count of global variables is unchanged - hooray!

While testing I found one more leak, this time caused by allocating a
structure for caching array type I/O functions and never freeing it.
Attached as separate patch.

Cheers,
Jan

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Urbański
Дата:
Сообщение: Re: Potential reference miscounts and segfaults in plpython.c
Следующее
От: Robert Haas
Дата:
Сообщение: Re: leakproof