database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00
Code Activity

I have attached the pltcl patch again, just in case. For the sake of clarity

Browse Source 
let's say this patch superscedes the previous one.

I have also attached a patch addressing the similar memory leak problem in
plpython. This includes a slight adjustment of the tests in the source
directory. The patch also includes a cosmetic change to remove a compiler
warning although I think the change makes the code look worse though.

BTW, by my reckoning the memory leak would occur with prepared plans and
without. If that is not the case then I've been barking up the wrong tree.

Nigel J. Andrews
This commit is contained in:
Bruce Momjian
2002-09-26 05:23:26 +00:00
parent 5ad4faf13a
commit b2c34e2bd1
4 changed files with 25 additions and 4 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.22 2002/09/04 22:51:23 petere Exp $
* $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.23 2002/09/26 05:23:26 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();
}