On Friday 30 April 2010 20:09:48 Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > On Friday 30 April 2010 19:39:32 Tom Lane wrote:
> >> Yeah. There's a leak of the tuptable in the CATCH path, too. Will fix.
> >
> > Yes, theres even more than that (measured it) in the error case. Will
> > have a look later today.
>
> Here's the patch I'm planning to apply --- working it back into the
> back branches now.
The one I measured was 9.0 only:
diff --git a/src/pl/plpython/plpython.c b/src/pl/plpython/plpython.c
index 6063628..a6dd9d0 100644
*** a/src/pl/plpython/plpython.c
--- b/src/pl/plpython/plpython.c
*************** plpython_inline_handler(PG_FUNCTION_ARGS
*** 538,546 ****
--- 538,548 ----
PLy_procedure_compile(proc, codeblock->source_text);
PLy_curr_procedure = proc;
PLy_function_handler(&fake_fcinfo, proc);
+ PLy_free(proc);
}
PG_CATCH();
{
+ PLy_free(proc);
PLy_curr_procedure = save_curr_proc;
PyErr_Clear();
PG_RE_THROW();
Found by running something like:
while true; do echo 'DO LANGUAGE plpythonu $$import
gc;gc.collect();plpy.execute("SELECT unknown"); $$;';done|psql -h /tmp -p 5433
postgres
The gc stuff is just to make real leaks way much easier to spot.
Andres
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
