aboutsummaryrefslogtreecommitdiff
path: root/src/pl/plpython/plpython.c
diff options
context:
space:
mode:
authorBruce Momjian <bruce@momjian.us>2002-10-14 04:20:52 +0000
committerBruce Momjian <bruce@momjian.us>2002-10-14 04:20:52 +0000
commit1f653ec31ef0f88af1216c0631605e859b4794a5 (patch)
treea2177dd7b6ef7f35f29115ae9d3730b7ba5ca432 /src/pl/plpython/plpython.c
parentdaaf999fcbfaab378e4ac2800d26cc04f12f1500 (diff)
downloadpostgresql-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.c13
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();
}