Re: Plpython crashing the backend in one easy step

Thanks, I assumed something like that.

I can very quickly provide at implementation that meets
these criteria (It's my option "b"), but it may be
less informative in terms of messages.

I'll have a look to see what I can do to supplement
the messages.

I also need to check if there's a memory leak after I
fix it.

I was aware of the example in plpgsql.

-Brad


* Tom Lane (tgl@sss.pgh.pa.us) [011113 17:08]:
> 
> 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