database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-14 18:42:34 +03:00
Code Activity

I have attached two patches as per:

Browse Source 
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
This commit is contained in:
Bruce Momjian
2002-10-14 04:20:52 +00:00
parent daaf999fcb
commit 1f653ec31e
4 changed files with 60 additions and 27 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.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();
}