From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: plpython memory leak uppon empty resultsets in all versions |
Date: | 2010-04-30 21:54:16 |
Message-ID: | 201004302354.17832.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Friday 30 April 2010 20:09:48 Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-04-30 21:57:04 | Re: plpython memory leak uppon empty resultsets in all versions |
Previous Message | Tom Lane | 2010-04-30 18:09:48 | Re: plpython memory leak uppon empty resultsets in all versions |