database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-19 13:42:17 +03:00
Code Activity

Back out /pl memory leak patch. Wait for new version.

Browse Source
This commit is contained in:
Bruce Momjian
2002-09-26 05:39:03 +00:00
parent ff5d4cbfca
commit 72f8efdc98
4 changed files with 4 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
src/pl/plpython/plpython.c
View File

@@ -29,7 +29,7 @@
* MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.23 2002/09/26 05:23:26 momjian Exp $
* $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.24 2002/09/26 05:39:03 momjian Exp $
*
*********************************************************************
*/
@@ -408,9 +408,7 @@ plpython_call_handler(PG_FUNCTION_ARGS)
else
PLy_restart_in_progress += 1;
if (proc)
{
Py_DECREF(proc->me);
}
RERAISE_EXC();
}
@@ -1843,14 +1841,7 @@ 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);
@@ -2383,8 +2374,6 @@ 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();
}