From 7efa8411cc56383a9b7ac2203f310d0db81f0580 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 16 Nov 2004 18:10:16 +0000 Subject: Rethink plpgsql's way of handling SPI execution during an exception block. We don't really want to start a new SPI connection, just keep using the old one; otherwise we have memory management problems as illustrated by John Kennedy's bug report of today. This requires a bit of a hack to ensure the SPI stack state is properly restored, but then again what we were doing before was a hack too, strictly speaking. Add a regression test to cover this case. --- src/backend/executor/spi.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'src/backend/executor') diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c index b533470e1d5..4549ba00080 100644 --- a/src/backend/executor/spi.c +++ b/src/backend/executor/spi.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/spi.c,v 1.131 2004/10/13 01:25:10 neilc Exp $ + * $PostgreSQL: pgsql/src/backend/executor/spi.c,v 1.132 2004/11/16 18:10:13 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -270,6 +270,14 @@ SPI_pop(void) _SPI_curid--; } +/* Restore state of SPI stack after aborting a subtransaction */ +void +SPI_restore_connection(void) +{ + Assert(_SPI_connected >= 0); + _SPI_curid = _SPI_connected - 1; +} + /* Parse, plan, and execute a querystring */ int SPI_execute(const char *src, bool read_only, int tcount) -- cgit v1.2.3