Re: Plpython crashing the backend in one easy step - fix - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Plpython crashing the backend in one easy step - fix |
Date | |
Msg-id | 384.1005934299@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Plpython crashing the backend in one easy step - fix (Bradley McLean <brad@bradm.net>) |
Responses |
Re: Plpython crashing the backend in one easy step - fix
|
List | pgsql-hackers |
Bradley McLean <brad@bradm.net> writes: > Okay, the attached patch contains the following: I have checked over and applied this patch. It appeared that you incorporated the earlier version of Kevin's patch rather than the later one. I made the further changes indicated by the attached diff, which I think are all the differences between Kevin's two submissions, but I'd appreciate it if both of you would review what's now in CVS and confirm it's okay. (There'll probably be a beta3 release later today, so you can look at that if it's easier than CVS.) One thing I noticed while running the selftest on a LinuxPPC box is that the "feature" test output differed: --- feature.expected Fri May 25 11:48:33 2001 +++ feature.output Fri Nov 16 13:00:15 2001 @@ -29,7 +29,7 @@(1 row)SELECT import_fail(); -NOTICE: ('import socket failed -- untrusted dynamic module: _socket',) +NOTICE: ('import socket failed -- untrusted dynamic module: socket',) import_fail -------------------- failed asexpected I assume you guys both get the "expected" output? Perhaps this should be noted as a possible platform discrepancy. > Tom's requirement that we always reraise the longjmp is at odds with > the original design of plpython, which attempted to allow a plpython > function to use Python's exception handling to recover when an > embedded SPI call failed. There is no way to do this that I can > see without halting the propogation of the longjmp. > Thus, the semantics of 'execute' calls from plpython have been changed: > should the backend throw an error, the plpython function will be > summarily aborted. Previously, it could attempt to catch a python > exception. > Note that this does create some redundant exception handling paths > in upper level methods within this module that are no longer used. > I have not yet removed them, but will happily do so (in a careful > deliberate manner) once sure that there is no alternative way to > restore the python level exception handling. I would suggest leaving it as-is for now. Sooner or later we will probably try to reduce the severity of most errors, and at that point it'd become worthwhile to re-enable error trapping in plpython. regards, tom lane *** plpython.c~ Fri Nov 16 12:19:38 2001 --- plpython.c Fri Nov 16 12:24:43 2001 *************** *** 292,297 **** --- 292,298 ---- "binascii", "calendar", "cmath", + "codecs", "errno", "marshal", "math", *************** *** 325,330 **** --- 326,332 ---- "hexrevision", "maxint", "maxunicode", + "platform", "version", "version_info" };
pgsql-hackers by date: