Re: Plpython crashing the backend in one easy step

Bradley McLean <brad(at)bradm(dot)net> writes:
> 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.

Yes, as in "it's totally unsafe". Suppressing an elog(ERROR) is
a *big* no-no at present, because way too much stuff relies on
post-abort cleanup to clean up whatever problem is being reported.
You cannot allow the transaction to continue after the error, and
you most certainly mustn't cavalierly reset the error handling state.

The only things you should be doing with longjmp trapping are
(a) doing any cleanup that Python itself has to have before you
re-propagate the longjmp, or
(b) issuing elog(NOTICE) to help identify the error location
before you re-propagate the longjmp.

plpgsql contains an example of doing (b).

Not propagating the longjmp, which is what the code seems to be doing
at present, is not acceptable. I had not looked at this code closely,
but as-is it is a huge reliability hazard. I will insist on removing
plpython from 7.2 entirely if this can't be fixed before release.

regards, tom lane