]> granicus.if.org Git - postgresql/commit
Fix memory leaks in PL/Python.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 5 Nov 2015 18:52:30 +0000 (13:52 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 5 Nov 2015 18:52:40 +0000 (13:52 -0500)
commit8c75ad436f75fc629b61f601ba884c8f9313c9af
tree80d33393d43c659c57021bb129a5c8ba0734329c
parent64b2e7ad917a9a7814904d0f6dbde52cefbcfa00
Fix memory leaks in PL/Python.

Previously, plpython was in the habit of allocating a lot of stuff in
TopMemoryContext, and it was very slipshod about making sure that stuff
got cleaned up; in particular, use of TopMemoryContext as fn_mcxt for
function calls represents an unfixable leak, since we generally don't
know what the called function might have allocated in fn_mcxt.  This
results in session-lifespan leakage in certain usage scenarios, as for
example in a case reported by Ed Behn back in July.

To fix, get rid of all the retail allocations in TopMemoryContext.
All long-lived allocations are now made in sub-contexts that are
associated with specific objects (either pl/python procedures, or
Python-visible objects such as cursors and plans).  We can clean these
up when the associated object is deleted.

I went so far as to get rid of PLy_malloc completely.  There were a
couple of places where it could still have been used safely, but on
the whole it was just an invitation to bad coding.

Haribabu Kommi, based on a draft patch by Heikki Linnakangas;
some further work by me
15 files changed:
src/pl/plpython/plpy_cursorobject.c
src/pl/plpython/plpy_cursorobject.h
src/pl/plpython/plpy_exec.c
src/pl/plpython/plpy_main.c
src/pl/plpython/plpy_main.h
src/pl/plpython/plpy_planobject.c
src/pl/plpython/plpy_planobject.h
src/pl/plpython/plpy_procedure.c
src/pl/plpython/plpy_procedure.h
src/pl/plpython/plpy_spi.c
src/pl/plpython/plpy_subxactobject.c
src/pl/plpython/plpy_typeio.c
src/pl/plpython/plpy_typeio.h
src/pl/plpython/plpy_util.c
src/pl/plpython/plpy_util.h