Re: Plpython crashing the backend in one easy step - fix

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" };