Re: pl/python long-lived allocations in datum->dict transformation
Jan Urbański <wulczer@wulczer.org>
From: Jan Urbański <wulczer@wulczer.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-20T00:09:21Z
Lists: pgsql-hackers
Attachments
- plpython-execution-contexts.patch (text/x-diff) patch
- plpython-array-leak.patch (text/x-diff) patch
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