database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00
Code Activity

Rethink plpgsql's way of handling SPI execution during an exception block.

Browse Source 
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.
This commit is contained in:
Tom Lane
2004-11-16 18:10:16 +00:00
parent 2bb3bcfcf9
commit 7efa8411cc
5 changed files with 72 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/executor/spi.c
View File

@ -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)