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

Bradley McLean <brad(at)bradm(dot)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 as expected

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