Skip to content

Commit b2c34e2

Browse files
bmomjianbmomjian
committed
I have attached the pltcl patch again, just in case. For the sake of clarity
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
1 parent 5ad4faf commit b2c34e2

File tree

4 files changed

+25
-4
lines changed

4 files changed

+25
-4
lines changed

‎src/pl/plpython/feature.expected

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ SELECT global_test_two();
2929
(1 row)
3030

3131
SELECT import_fail();
32-
WARNING: ('import socket failed -- untrusted dynamic module: _socket',)
32+
NOTICE: ('import socket failed -- untrusted dynamic module: _socket',)
3333
import_fail
3434
--------------------
3535
failed as expected

‎src/pl/plpython/plpython.c

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@
2929
* MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
3030
*
3131
* IDENTIFICATION
32-
* $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.22 2002/09/04 22:51:23 petere Exp $
32+
* $Header: /cvsroot/pgsql/src/pl/plpython/plpython.c,v 1.23 2002/09/26 05:23:26 momjian Exp $
3333
*
3434
*********************************************************************
3535
*/
@@ -408,7 +408,9 @@ plpython_call_handler(PG_FUNCTION_ARGS)
408408
else
409409
PLy_restart_in_progress += 1;
410410
if (proc)
411+
{
411412
Py_DECREF(proc->me);
413+
}
412414
RERAISE_EXC();
413415
}
414416

@@ -1841,7 +1843,14 @@ PLy_plan_dealloc(PyObject * arg)
18411843
*
18421844
* FIXME -- leaks saved plan on object destruction. can this be
18431845
* avoided?
1846+
* I think so. A function prepares and then execp's a statement.
1847+
* When we come to deallocate the 'statement' object we obviously
1848+
* no long need the plan. Even if we did, without the object
1849+
* we're never going to be able to use it again.
1850+
* In the against arguments: SPI_saveplan has stuck this under
1851+
* the top context so there must be a reason for doing that.
18441852
*/
1853+
pfree(ob->plan);
18451854
}
18461855
if (ob->types)
18471856
PLy_free(ob->types);
@@ -2374,6 +2383,8 @@ PLy_spi_execute_fetch_result(SPITupleTable *tuptable, int rows, int status)
23742383
PyList_SetItem(result->rows, i, row);
23752384
}
23762385
PLy_typeinfo_dealloc(&args);
2386+
2387+
SPI_freetuptable(tuptable);
23772388
}
23782389
RESTORE_EXC();
23792390
}

‎src/pl/plpython/plpython_schema.sql

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ CREATE TABLE taxonomy (
2020

2121
CREATE TABLE entry (
2222
accession text not null primary key,
23-
eid serial,
23+
eid serial unique,
2424
txid int2 not null references taxonomy(id)
2525
) ;
2626

‎src/pl/tcl/pltcl.c

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@
3131
* ENHANCEMENTS, OR MODIFICATIONS.
3232
*
3333
* IDENTIFICATION
34-
* $Header: /cvsroot/pgsql/src/pl/tcl/pltcl.c,v 1.62 2002/09/21 18:39:26 tgl Exp $
34+
* $Header: /cvsroot/pgsql/src/pl/tcl/pltcl.c,v 1.63 2002/09/26 05:23:26 momjian Exp $
3535
*
3636
**********************************************************************/
3737

@@ -1647,6 +1647,7 @@ pltcl_SPI_exec(ClientData cdata, Tcl_Interp *interp,
16471647
pltcl_set_tuple_values(interp, arrayname, 0, tuples[0], tupdesc);
16481648
sprintf(buf, "%d", ntuples);
16491649
Tcl_SetResult(interp, buf, TCL_VOLATILE);
1650+
SPI_freetuptable(SPI_tuptable);
16501651
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
16511652
return TCL_OK;
16521653
}
@@ -1668,15 +1669,19 @@ pltcl_SPI_exec(ClientData cdata, Tcl_Interp *interp,
16681669
continue;
16691670
if (loop_rc == TCL_RETURN)
16701671
{
1672+
SPI_freetuptable(SPI_tuptable);
16711673
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
16721674
return TCL_RETURN;
16731675
}
16741676
if (loop_rc == TCL_BREAK)
16751677
break;
1678+
SPI_freetuptable(SPI_tuptable);
16761679
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
16771680
return TCL_ERROR;
16781681
}
16791682

1683+
SPI_freetuptable(SPI_tuptable);
1684+
16801685
/************************************************************
16811686
* Finally return the number of tuples
16821687
************************************************************/
@@ -2207,6 +2212,7 @@ pltcl_SPI_execp(ClientData cdata, Tcl_Interp *interp,
22072212
{
22082213
if (ntuples > 0)
22092214
pltcl_set_tuple_values(interp, arrayname, 0, tuples[0], tupdesc);
2215+
SPI_freetuptable(SPI_tuptable);
22102216
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
22112217
sprintf(buf, "%d", ntuples);
22122218
Tcl_SetResult(interp, buf, TCL_VOLATILE);
@@ -2229,15 +2235,19 @@ pltcl_SPI_execp(ClientData cdata, Tcl_Interp *interp,
22292235
continue;
22302236
if (loop_rc == TCL_RETURN)
22312237
{
2238+
SPI_freetuptable(SPI_tuptable);
22322239
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
22332240
return TCL_RETURN;
22342241
}
22352242
if (loop_rc == TCL_BREAK)
22362243
break;
2244+
SPI_freetuptable(SPI_tuptable);
22372245
memcpy(&Warn_restart, &save_restart, sizeof(Warn_restart));
22382246
return TCL_ERROR;
22392247
}
22402248

2249+
SPI_freetuptable(SPI_tuptable);
2250+
22412251
/************************************************************
22422252
* Finally return the number of tuples
22432253
************************************************************/

0 commit comments

Comments
 (0)