I need some expert guidance here. Suppose you have:
CREATE FUNCTION crash() RETURNS varchar AS '
plpy.execute("syntax error")
' language 'plpython';
Here are three possible behaviors:
(A)
a123=# select crash();
ERROR: parser: parse error at or near "syntax"
ERROR: plpython: Call of function `__plpython_procedure_crash_41133' failed.
plpy.SPIError: Unknown error in PLy_spi_execute_query.
FATAL 2: elog: error during error recovery, giving up!
server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore or while processing
therequest.
The connection to the server was lost. Attempting reset: Failed.
!#
(B)
a123=# select crash();
ERROR: parser: parse error at or near "syntax"
a123=#
(C)
a123=# select crash();
ERROR: parser: parse error at or near "syntax"
ERROR: plpython: Call of function `__plpython_procedure_crash_41133' failed.
plpy.SPIError: Unknown error in PLy_spi_execute_query.
a123=#
Option (A) is the current code.
Fixing this happens near line 2290 (could be off a bit, I have some other
patches in this file), in the first if clause in PLy_spi_execute_query.
The DECLARE_EXC, SAVE_EXC, TRAP_EXC, RESTORE_EXC, RERAISE_EXC macros
are wrappers around sigsetjmp and longjmp, and are used to intercept
the elog calls occurring when plpython calls spi.
In Option (A), we return NULL, which causes the next level of code
to call elog. Elog notices that we're already in an Error state, and
shuts down the backend.
In Option (B), I replace the 'return NULL' with a RERAISE_EXC, which
allows elog to function normally, albeit without any cleanup of the
plpython environment or useful messages.
In Option (C), I set the global "InError" flag to false, and then
return NULL, causing all of the error messages to come out and
plpython to clean up gracefully, no backend crash. However, this
seems to be an unprecedented approach, and I could be missing
something big.
There's probably an Option (D) that I'm overlooking.
HELP! (thanks)
-Brad