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)
pgsql-committers by date:
Соглашаюсь с условиями обработки персональных данных