On 28/03/11 17:25, Stephen Frost wrote:
> * Jan Urbański (wulc...@wulczer.org) wrote:
>> On 28/03/11 04:31, Tom Lane wrote:
>>>> Do the other PLs we ship need similar fixes?
>>>
>>> Offhand I think the other PLs leave management of prepared plans to the
>>> user. If there are any places where they cache plans behind the scenes,
>>> maybe a similar fix would be appropriate.
>>
>> FWIW I executed
>>
>> do $$ plpy.execute("select 1 from pg_class") $$ language plpythonu;
>>
>> 10k times in a session and the backend grew a lot in memory and never
>> released it. I can't offhand see where the memory went, I'll try to
>> investigate in the evening.
>
> I'm about 90% sure that they all have this problem.. I havn't had a
> chance to look at how Tom fixed pl/pgsql (I didn't think it'd be easy to
> do w/o coming up with a way to explicitly tell the PL to release
> something) so perhaps I'm mistaken, but they all share very similar
> code..
Valgrind showed me the way. PFA a trivial patch to avoid leaking a
PLyProcedure struct in inline blocks.
Prepared plans get cleaned up currectly, the SPI plan is deallocated
when the Python plan object is garbage collected.
Cheers,
Jan
diff --git a/src/pl/plpython/plpython.c b/src/pl/plpython/plpython.c
index dd2b919..58d070f 100644
--- a/src/pl/plpython/plpython.c
+++ b/src/pl/plpython/plpython.c
@@ -626,6 +626,7 @@ plpython_inline_handler(PG_FUNCTION_ARGS)
PG_CATCH();
{
PLy_procedure_delete(proc);
+ PLy_free(proc);
PLy_curr_procedure = save_curr_proc;
PyErr_Clear();
PG_RE_THROW();
@@ -633,6 +634,7 @@ plpython_inline_handler(PG_FUNCTION_ARGS)
PG_END_TRY();
PLy_procedure_delete(proc);
+ PLy_free(proc);
/* Pop the error context stack */
error_context_stack = plerrcontext.previous;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
