Re: pl/python long-lived allocations in datum->dict transformation - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: pl/python long-lived allocations in datum->dict transformation
Date
Msg-id 4F418F31.1070204@wulczer.org
Whole thread Raw
In response to Re: pl/python long-lived allocations in datum->dict transformation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pl/python long-lived allocations in datum->dict transformation
List 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

Attachment

pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: Potential reference miscounts and segfaults in plpython.c
Next
From: Robert Haas
Date:
Subject: Re: leakproof