Re: Plpython crashing the backend in one easy step

Has this been addressed?

---------------------------------------------------------------------------

> Bradley McLean <brad@bradm.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026