From 1f653ec31ef0f88af1216c0631605e859b4794a5 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Mon, 14 Oct 2002 04:20:52 +0000 Subject: I have attached two patches as per: 1) pltcl: Add SPI_freetuptable() calls to avoid memory leaks (Me + Neil Conway) Change sprintf()s to snprintf()s (Neil Conway) Remove header files included elsewhere (Neil Conway) 2)plpython: Add SPI_freetuptable() calls to avoid memory leaks Cosemtic change to remove a compiler warning Notes: I have tested pltcl.c for a) the original leak problem reported for the repeated call of spi_exec in a TCL fragment and b) the subsequent report resulting from the use of spi_exec -array in a TCL fragment. The plpython.c patch is exactly the same as that applied to make revision 1.23, the plpython_schema.sql and feature.expected sections of the patch are also the same as last submited, applied and subsequently reversed out. It remains untested by me (other than via make check). However, this should be safe provided PyString_FromString() _copies_ the given string to make a PyObject. Nigel J. Andrews --- src/pl/plpython/plpython.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'src/pl/plpython/plpython.c') diff --git a/src/pl/plpython/plpython.c b/src/pl/plpython/plpython.c index 86f39cd4d09..005d85e9ce1 100644 --- a/src/pl/plpython/plpython.c +++ b/src/pl/plpython/plpython.c @@ -29,7 +29,7 @@ * MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. * * IDENTIFICATION - * $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.24 2002/09/26 05:39:03 momjian Exp $ + * $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.25 2002/10/14 04:20:52 momjian Exp $ * ********************************************************************* */ @@ -408,7 +408,9 @@ plpython_call_handler(PG_FUNCTION_ARGS) else PLy_restart_in_progress += 1; if (proc) + { Py_DECREF(proc->me); + } RERAISE_EXC(); } @@ -1841,7 +1843,14 @@ PLy_plan_dealloc(PyObject * arg) * * FIXME -- leaks saved plan on object destruction. can this be * avoided? + * I think so. A function prepares and then execp's a statement. + * When we come to deallocate the 'statement' object we obviously + * no long need the plan. Even if we did, without the object + * we're never going to be able to use it again. + * In the against arguments: SPI_saveplan has stuck this under + * the top context so there must be a reason for doing that. */ + pfree(ob->plan); } if (ob->types) PLy_free(ob->types); @@ -2374,6 +2383,8 @@ PLy_spi_execute_fetch_result(SPITupleTable *tuptable, int rows, int status) PyList_SetItem(result->rows, i, row); } PLy_typeinfo_dealloc(&args); + + SPI_freetuptable(tuptable); } RESTORE_EXC(); } -- cgit v1.2.3