Log Message:
-----------
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.
Modified Files:
--------------
pgsql/src/backend/executor:
spi.c (r1.131 -> r1.132)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c.diff?r1=1.131&r2=1.132)
pgsql/src/include/executor:
spi.h (r1.49 -> r1.50)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/spi.h.diff?r1=1.49&r2=1.50)
pgsql/src/pl/plpgsql/src:
pl_exec.c (r1.120 -> r1.121)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c.diff?r1=1.120&r2=1.121)
pgsql/src/test/regress/expected:
plpgsql.out (r1.21 -> r1.22)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/plpgsql.out.diff?r1=1.21&r2=1.22)
pgsql/src/test/regress/sql:
plpgsql.sql (r1.16 -> r1.17)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/plpgsql.sql.diff?r1=1.16&r2=1.17)
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
