diff options
author | Bruce Momjian <bruce@momjian.us> | 2002-10-14 04:20:52 +0000 |
---|---|---|
committer | Bruce Momjian <bruce@momjian.us> | 2002-10-14 04:20:52 +0000 |
commit | 1f653ec31ef0f88af1216c0631605e859b4794a5 (patch) | |
tree | a2177dd7b6ef7f35f29115ae9d3730b7ba5ca432 /src/pl/plpython/plpython.c | |
parent | daaf999fcbfaab378e4ac2800d26cc04f12f1500 (diff) | |
download | postgresql-1f653ec31ef0f88af1216c0631605e859b4794a5.tar.gz postgresql-1f653ec31ef0f88af1216c0631605e859b4794a5.zip |
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
Diffstat (limited to 'src/pl/plpython/plpython.c')
-rw-r--r-- | src/pl/plpython/plpython.c | 13 |
1 files changed, 12 insertions, 1 deletions
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(); } |