Thread: pl/python custom exceptions for SPI
Here's a patch implementing custom Python exceptions for SPI errors mentioned in http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's an incremental patch on top of the explicit-subxacts patch sent eariler. Git branch for this patch: https://github.com/wulczer/postgres/tree/custom-spi-exceptions. What the patch does is provide a Python exception per each error defined in utils/errcodes.h, and then raise the corresponding exception when a SPI call fails. The parsing of errcodes.h in the Makefile is a little grotty and would probably have to be ported to the Windows build system, which I have no idea about. With this patch you can do: from plpy import spiexceptions try: plpy.execute("insert into t values (4)") catch spiexceptions.UniqueViolation: plpy.notice("unique constraint violation") catch spiexceptions.NotNullViolation: plpy.notice("not null constraint violation") All exceptions inherint from plpy.SPIError, so code thta just catches a blanket SPIErorr will continue to work. The patch lacks user-facing docs, if it gets accepted I'll write some. Not sure if we should provide a table similar to http://www.postgresql.org/docs/current/static/errcodes-appendix.html, or just refer to that table and state that the rule is changing underscores to camel case... Also, I just realised that this patch does not really depend on the explicit-subxacts change, but rather only on the spi-in-subxacts, so if need be I can generate it as an incremental changeset ofer the latter and not the former. Cheers, Jan
Attachment
On 23/12/10 15:40, Jan Urbański wrote: > Here's a patch implementing custom Python exceptions for SPI errors > mentioned in > http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's > an incremental patch on top of the explicit-subxacts patch sent eariler. I changed that patch to use Perl instead of sed to generate the exceptions, which should be a more portable. It's still not nice, and I think the way forward is to have a common format for SQLSTATE conditions, as proposed in http://archives.postgresql.org/message-id/4D19C93C.5000703@wulczer.org. I failed to follow on with that patch because I couldn't figure out how to persuade the buildsystem to generate errcodes.h early enough for the rest of the system to compile, not to mention doing it for the MSVC build system. Cheers, Jan
Attachment
On 10.1.2011 17:20, Jan Urbański wrote: <blockquote cite="mid:4D2B31DC.4010307@wulczer.org" type="cite"><pre wrap="">On23/12/10 15:40, Jan Urbański wrote: </pre><blockquote type="cite"><pre wrap="">Here's a patch implementing custom Python exceptions for SPI errors mentioned in <a class="moz-txt-link-freetext" href="http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php">http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php</a>. It's an incremental patch on top of the explicit-subxacts patch sent eariler. </pre></blockquote><pre wrap=""> I changed that patch to use Perl instead of sed to generate the exceptions, which should be a more portable.</pre></blockquote> Why not python ?<br /><blockquote cite="mid:4D2B31DC.4010307@wulczer.org"type="cite"><pre wrap=""> It's still not nice, and I think the way forward is to have a common format for SQLSTATE conditions, as proposed in <a class="moz-txt-link-freetext" href="http://archives.postgresql.org/message-id/4D19C93C.5000703@wulczer.org">http://archives.postgresql.org/message-id/4D19C93C.5000703@wulczer.org</a>. I failed to follow on with that patch because I couldn't figure out how to persuade the buildsystem to generate errcodes.h early enough for the rest of the system to compile, not to mention doing it for the MSVC build system. Cheers, Jan </pre> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">-- -------------------------------------------- Hannu Krosing Senior Consultant, Infinite Scalability & Performance <a class="moz-txt-link-freetext" href="http://www.2ndQuadrant.com/books/">http://www.2ndQuadrant.com/books/</a></pre>
Hannu Krosing <hannu@2ndquadrant.com> writes: > On 10.1.2011 17:20, Jan Urbański wrote: >> I changed that patch to use Perl instead of sed to generate the >> exceptions, which should be a more portable. > Why not python ? Because we're not adding even more different tool requirements to the build process. Perl is what we've chosen to depend on, and there is no reason to use a different tool here. regards, tom lane
On 11/01/11 01:27, Tom Lane wrote: > Hannu Krosing <hannu@2ndquadrant.com> writes: >> On 10.1.2011 17:20, Jan Urbański wrote: >>> I changed that patch to use Perl instead of sed to generate the >>> exceptions, which should be a more portable. > >> Why not python ? > > Because we're not adding even more different tool requirements to the > build process. Perl is what we've chosen to depend on, and there is no > reason to use a different tool here. Yep, exactly. While looking at it again I fixed a problem with spiexceptions.h not being distributed (and IIRC we don't require Perl for tarball builds) and added generating it to the MSVC build system. Updated patch attached. Cheers, Jan
Attachment
On 11/01/11 12:20, Jan Urbański wrote: > On 11/01/11 01:27, Tom Lane wrote: >> Hannu Krosing <hannu@2ndquadrant.com> writes: >>> On 10.1.2011 17:20, Jan Urbański wrote: >>>> I changed that patch to use Perl instead of sed to generate the >>>> exceptions, which should be a more portable. Updated as an incremental patch on to of the recently sent version of explicit-subxacts.
Attachment
On 27/01/11 23:24, Jan Urbański wrote: > On 11/01/11 12:20, Jan Urbański wrote: >> On 11/01/11 01:27, Tom Lane wrote: >>> Hannu Krosing <hannu@2ndquadrant.com> writes: >>>> On 10.1.2011 17:20, Jan Urbański wrote: >>>>> I changed that patch to use Perl instead of sed to generate the >>>>> exceptions, which should be a more portable. > > Updated as an incremental patch on to of the recently sent version of > explicit-subxacts. Updated again.
Attachment
On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote: > On 27/01/11 23:24, Jan Urbański wrote: > > On 11/01/11 12:20, Jan Urbański wrote: > >> On 11/01/11 01:27, Tom Lane wrote: > >>> Hannu Krosing <hannu@2ndquadrant.com> writes: > >>>> On 10.1.2011 17:20, Jan Urbański wrote: > >>>>> I changed that patch to use Perl instead of sed to generate the > >>>>> exceptions, which should be a more portable. > > > > Updated as an incremental patch on to of the recently sent version of > > explicit-subxacts. > > Updated again. Why do the error messages print spiexceptions.SyntaxError instead of plpy.spiexceptions.SyntaxError? Is this intentional or just the way it comes out of Python? Please add some documentation. Not a list of all exceptions, but at least a paragraph that various kinds of specific exceptions may be generated, what package and module they are in, and how they relate.
On 10/02/11 20:24, Peter Eisentraut wrote: > On sön, 2011-02-06 at 20:44 +0100, Jan Urbański wrote: >> On 27/01/11 23:24, Jan Urbański wrote: >>> On 11/01/11 12:20, Jan Urbański wrote: >>>> On 11/01/11 01:27, Tom Lane wrote: >>>>> Hannu Krosing <hannu@2ndquadrant.com> writes: >>>>>> On 10.1.2011 17:20, Jan Urbański wrote: >>>>>>> I changed that patch to use Perl instead of sed to generate the >>>>>>> exceptions, which should be a more portable. >>> >>> Updated as an incremental patch on to of the recently sent version of >>> explicit-subxacts. >> >> Updated again. > > Why do the error messages print spiexceptions.SyntaxError instead of > plpy.spiexceptions.SyntaxError? Is this intentional or just the way it > comes out of Python? That's how traceback.format_exception() works IIRC, which is what the Python interpreter uses and what PL/Python mimicks in PLy_traceback. > Please add some documentation. Not a list of all exceptions, but at > least a paragraph that various kinds of specific exceptions may be > generated, what package and module they are in, and how they relate. Sure, Steve already asked for docs in another thread, and I'm writing them. Jan
On 11-02-10 03:13 PM, Jan Urbański wrote: > On 10/02/11 20:24, Peter Eisentraut wrote: Here is the rest of my review. Submission Review ------------------- Patch applies cleanly. Documentation is still outstanding but Jan has promised it soon. Usability Review ------------------- We don't have this for plpython, that we have a similar idea with plpgsql. I think this feature is useful and worth having. The CamelCase naming of the exceptions is consistent with how the built-in python exceptions are named (camel case). Feature Test --------------- I did basic testing of the feature (catching a few exception types thrown from both direct SQL and prepared statements) and the feature worked as expected. Performance Impact -------------------- The impact of mapping error codes to exception types shouldn't come into play unless an SPI error is returned and with the hash it should still be minimal. Code Review ------------- Ideally char * members of ExceptionMap would be const, but since many versions of python take a non-const value to PyErr_NewException that won't work :( After you search the for an exception in the hash you have: /* We really should find it, but just in case have a fallback */ Assert(entry != NULL); exc = entry ? entry->exc : PLy_exc_spi_error; I'm not sure the assert is needed here. Just falling back to the exception type seems reasonable and more desirable than an assert if showhow a new exception gets missed from the list. I don't feel that strongly on this. line 3575: PLy_elog(ERROR, "Failed to add the spiexceptions module"); "Failed" should be "failed" Other than that the patch looks fine to me. >>> >>> Updated again. >> >> Why do the error messages print spiexceptions.SyntaxError instead of >> plpy.spiexceptions.SyntaxError? Is this intentional or just the way it >> comes out of Python? > > That's how traceback.format_exception() works IIRC, which is what the > Python interpreter uses and what PL/Python mimicks in PLy_traceback. > >> Please add some documentation. Not a list of all exceptions, but at >> least a paragraph that various kinds of specific exceptions may be >> generated, what package and module they are in, and how they relate. > > Sure, Steve already asked for docs in another thread, and I'm writing them. > > Jan >
On 10/02/11 22:26, Steve Singer wrote: > On 11-02-10 03:13 PM, Jan Urbański wrote: >> On 10/02/11 20:24, Peter Eisentraut wrote: > > Here is the rest of my review. Thanks! > Ideally char * members of ExceptionMap would be const, but since many > versions of python take a non-const value to PyErr_NewException that > won't work :( Yeah, I got "discards qualifier" warnings when I tried to declare it as const :( > After you search the for an exception in the hash you have: > > /* We really should find it, but just in case have a fallback */ > Assert(entry != NULL); > exc = entry ? entry->exc : PLy_exc_spi_error; > > I'm not sure the assert is needed here. Just falling back to the > exception type seems reasonable and more desirable than an assert if > showhow a new exception gets missed from the list. I don't feel that > strongly on this. Maybe the comment doesn't explain this enough. My intention was that in regular builds you have a fallback and if you're missing an entry in the exceptions hash, you just get SPIError. But in assert-enabled builds you get an error, so you can detect it and fix the exceptions hash. > line 3575: PLy_elog(ERROR, "Failed to add the spiexceptions module"); > "Failed" should be "failed" Gah, I'll never learn. Will fix. > Other than that the patch looks fine to me. Thanks, I'll have the docs ready by today (and I should've have them by yesterday :/). Jan
On 11/02/11 10:53, Jan Urbański wrote: > On 10/02/11 22:26, Steve Singer wrote: Here's an updated patch with documentation. It's an incremental patch on top of the latest explicit-subxacts version. Cheers, Jan
Attachment
On 11-02-12 05:58 AM, Jan Urbański wrote:
This looks fine. I've attached a one word documentation change to go o top of the patch.
I'll let Peter decide if he likes those assert's or not. I don't have a good enough sense of if we often use asserts in that fashion elsewhere.
On 11/02/11 10:53, Jan Urbański wrote:On 10/02/11 22:26, Steve Singer wrote:Here's an updated patch with documentation. It's an incremental patch on top of the latest explicit-subxacts version.
This looks fine. I've attached a one word documentation change to go o top of the patch.
I'll let Peter decide if he likes those assert's or not. I don't have a good enough sense of if we often use asserts in that fashion elsewhere.
Cheers, Jan
Attachment
On lör, 2011-02-12 at 11:58 +0100, Jan Urbański wrote: > On 11/02/11 10:53, Jan Urbański wrote: > > On 10/02/11 22:26, Steve Singer wrote: > > Here's an updated patch with documentation. It's an incremental patch on > top of the latest explicit-subxacts version. Committed.
Peter Eisentraut <peter_e@gmx.net> writes: > On lör, 2011-02-12 at 11:58 +0100, Jan Urbański wrote: >> Here's an updated patch with documentation. It's an incremental patch on >> top of the latest explicit-subxacts version. > Committed. I'm seeing a core dump as well as multiple inconsistencies in error message spelling in the plpython regression tests on a Fedora 13 box (python 2.6.4). Several buildfarm critters don't look too happy either. regards, tom lane
On mån, 2011-02-28 at 12:08 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > On lör, 2011-02-12 at 11:58 +0100, Jan Urbański wrote: > >> Here's an updated patch with documentation. It's an incremental patch on > >> top of the latest explicit-subxacts version. > > > Committed. > > I'm seeing a core dump as well as multiple inconsistencies in error > message spelling in the plpython regression tests on a Fedora 13 box > (python 2.6.4). Several buildfarm critters don't look too happy either. Fixed. (Well, some of it. We'll see ...)
Peter Eisentraut <peter_e@gmx.net> writes: > On mån, 2011-02-28 at 12:08 -0500, Tom Lane wrote: >> I'm seeing a core dump as well as multiple inconsistencies in error >> message spelling in the plpython regression tests on a Fedora 13 box >> (python 2.6.4). Several buildfarm critters don't look too happy either. > Fixed. (Well, some of it. We'll see ...) Core dump is still there. It appears to be a python assertion failure. I installed python's debuginfo and got this backtrace: Program terminated with signal 6, Aborted. #0 0x00000032a36328f5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.2-6.fc12.x86_64 krb5-libs-1.7.1-17.fc13.x86_64 libcom_err-1.41.10-7.fc13.x86_64libselinux-2.0.94-2.fc13.x86_64 openssl-1.0.0c-1.fc13.x86_64 zlib-1.2.3-23.fc12.x86_64 (gdb) bt #0 0x00000032a36328f5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000032a36340d5 in abort () at abort.c:92 #2 0x00000032a362b8b5 in __assert_fail (assertion=0x32a5b46391 "gc->gc.gc_refs != 0", file=<value optimized out>, line=277,function=<value optimized out>) at assert.c:81 #3 0x00000032a5b0853e in visit_decref (op=<module at remote 0x7f11c3666d38>, data=<value optimized out>) at Modules/gcmodule.c:277 #4 0x00000032a5a7cbd9 in dict_traverse (op= {'info': <built-in function info>, 'notice': <built-in function notice>, 'Fatal':<type at remote 0x1bba7e0>, 'log': <built-in function log>, 'prepare': <built-in function prepare>, 'spiexceptions':<module at remote 0x7f11c3666d38>, 'SPIError': <type at remote 0x1bbacc0>, 'Error': <type at remote 0x1bba300>,'execute': <built-in function execute>, '__package__': None, 'quote_ident': <built-in function quote_ident>, 'warning':<built-in function warning>, 'subtransaction': <built-in function subtransaction>, 'quote_literal': <built-in functionquote_literal>, 'quote_nullable': <built-in function quote_nullable>, 'error': <built-in function error>, 'debug':<built-in function debug>, '__name__': 'plpy', 'fatal': <built-in function fatal>, '__doc__': None}, visit=0x32a5b084c0<visit_decref>, arg=0x0) at Objects/dictobject.c:2003 #5 0x00000032a5b08c9f in subtract_refs (generation=1) at Modules/gcmodule.c:296 #6 collect (generation=1) at Modules/gcmodule.c:817 #7 0x00000032a5b096fa in collect_generations (basicsize=<value optimized out>) at Modules/gcmodule.c:924 #8 _PyObject_GC_Malloc (basicsize=<value optimized out>) at Modules/gcmodule.c:1363 #9 0x00000032a5b0972e in _PyObject_GC_NewVar (tp=0x32a5d899a0, nitems=1) at Modules/gcmodule.c:1383 #10 0x00000032a5a9703f in PyTuple_New (size=1) at Objects/tupleobject.c:69 #11 0x00000032a5af3697 in r_object (p=0x7fffe1f5f330) at Python/marshal.c:788 #12 0x00000032a5af389c in r_object (p=0x7fffe1f5f330) at Python/marshal.c:927 #13 0x00000032a5af36dd in r_object (p=0x7fffe1f5f330) at Python/marshal.c:794 #14 0x00000032a5af389c in r_object (p=0x7fffe1f5f330) at Python/marshal.c:927 #15 0x00000032a5af36dd in r_object (p=0x7fffe1f5f330) at Python/marshal.c:794 #16 0x00000032a5af389c in r_object (p=0x7fffe1f5f330) at Python/marshal.c:927 #17 0x00000032a5af3fd8 in PyMarshal_ReadObjectFromString (str=<value optimized out>, len=<value optimized out>) at Python/marshal.c:1107 #18 0x00000032a5af5952 in PyMarshal_ReadLastObjectFromFile (fp=0x1c66e50) at Python/marshal.c:1066 #19 0x00000032a5aedb39 in read_compiled_module (cpathname=0x7fffe1f63540 "/usr/lib64/python2.6/string.pyc", fp=<value optimizedout>) at Python/import.c:767 #20 0x00000032a5aef69d in load_source_module (name=0x7fffe1f656a0 "string", pathname=0x7fffe1f645c0 "/usr/lib64/python2.6/string.py",fp=0x1c29b30) at Python/import.c:991 #21 0x00000032a5af0cb5 in import_submodule (mod=None, subname=0x7fffe1f656a0 "string", fullname=0x7fffe1f656a0 "string")at Python/import.c:2589 #22 0x00000032a5af0f34 in load_next (mod=None, altmod=None, p_name=<value optimized out>, buf=0x7fffe1f656a0 "string", p_buflen=0x7fffe1f65698) at Python/import.c:2409 #23 0x00000032a5af1582 in import_module_level (name=0x0, globals=<value optimized out>, locals=<value optimized out>, fromlist=None,level=<value optimized out>) at Python/import.c:2131 #24 0x00000032a5af22c4 in PyImport_ImportModuleLevel (name=0x7f11c40c2084 "string", globals= {'plpy': <module at remote0x7f11c3666ad0>, 'GD': {}, 'args': [], '__builtins__': <module at remote 0x7f11c4158830>, '__name__': '__main__', 'SD':{}, '__doc__': None, '__plpython_procedure_import_succeed_41194': <function at remote 0x7f11c3652aa0>, '__package__':None}, locals=None, fromlist=None, level=<value optimized out>) at Python/import.c:2182 #25 0x00000032a5ad762f in builtin___import__ (self=<value optimized out>, args=<value optimized out>, kwds=<value optimizedout>) at Python/bltinmodule.c:48 #26 0x00000032a5a43db3 in PyObject_Call (func=<built-in function __import__>, arg=<value optimized out>, kw=<value optimizedout>) at Objects/abstract.c:2492 #27 0x00000032a5ad7ba3 in PyEval_CallObjectWithKeywords (func=<built-in function __import__>, arg= ('string', {'plpy':<module at remote 0x7f11c3666ad0>, 'GD': {}, 'args': [], '__builtins__': <module at remote 0x7f11c4158830>, '__name__':'__main__', 'SD': {}, '__doc__': None, '__plpython_procedure_import_succeed_41194': <function at remote 0x7f11c3652aa0>,'__package__': None}, None, None), kw=<value optimized out>) at Python/ceval.c:3633 #28 0x00000032a5ada844 in PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2192 #29 0x00000032a5ade312 in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:3850 #30 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:3785 #31 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:2445 #32 0x00000032a5adf4e9 in PyEval_EvalCodeEx (co=0x7f11c36526c0, globals=<value optimized out>, locals=<value optimized out>,args=<value optimized out>, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3026 #33 0x00000032a5adf5b2 in PyEval_EvalCode (co=<value optimized out>, globals=<value optimized out>, locals=<value optimizedout>) at Python/ceval.c:526 #34 0x00007f11c418cab2 in PLy_procedure_call (proc=0x1c2c9d8, kargs=<value optimized out>, vargs=<value optimized out>) atplpython.c:1317 #35 0x00007f11c418cdfe in PLy_function_handler (fcinfo=0x1c3fd30, proc=0x1c2c9d8) at plpython.c:1091 #36 0x00007f11c418fb77 in plpython_call_handler (fcinfo=0x1c3fd30) at plpython.c:569 #37 0x0000000000588100 in ExecMakeFunctionResult (fcache=0x1c3fcc0, econtext=0x1c3fa98, isNull=0x1c40670 "\177~\177\177\177\177\177\177\270\004\253\001", isDone=<value optimized out>) at execQual.c:1826 #38 0x00000000005831b6 in ExecTargetList (projInfo=<value optimized out>, isDone=0x7fffe1f6703c) at execQual.c:5123 #39 ExecProject (projInfo=<value optimized out>, isDone=0x7fffe1f6703c) at execQual.c:5338 #40 0x000000000059b65b in ExecResult (node=0x1c3f980) at nodeResult.c:155 #41 0x0000000000582738 in ExecProcNode (node=0x1c3f980) at execProcnode.c:367 #42 0x0000000000581496 in ExecutePlan (queryDesc=0x19e4df8, direction=<value optimized out>, count=0) at execMain.c:1385 #43 standard_ExecutorRun (queryDesc=0x19e4df8, direction=<value optimized out>, count=0) at execMain.c:311 #44 0x000000000065d5d7 in PortalRunSelect (portal=0x19e2de8, forward=<value optimized out>, count=0, dest=0x1c3de28) at pquery.c:950 #45 0x000000000065e9f0 in PortalRun (portal=0x19e2de8, count=9223372036854775807, isTopLevel=1 '\001', dest=0x1c3de28, altdest=0x1c3de28,completionTag= 0x7fffe1f672a0 "") at pquery.c:794 #46 0x000000000065ae39 in exec_simple_query (query_string=0x1a70ac8 "SELECT import_succeed();") at postgres.c:1059 #47 0x000000000065bdf0 in PostgresMain (argc=<value optimized out>, argv=<value optimized out>, username=<value optimizedout>) at postgres.c:3943 #48 0x0000000000615081 in BackendRun () at postmaster.c:3590 #49 BackendStartup () at postmaster.c:3275 #50 ServerLoop () at postmaster.c:1449 #51 0x000000000061795f in PostmasterMain (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:1110 #52 0x00000000005b2e70 in main (argc=3, argv=0x19c3910) at main.c:199 Don't know python enough to do anything useful with this, but the reference to "gc_refs" sure makes it look like something is dropping the ball on when to do INCREF/DECREF. regards, tom lane
On 28/02/11 19:38, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> On mån, 2011-02-28 at 12:08 -0500, Tom Lane wrote: >>> I'm seeing a core dump as well as multiple inconsistencies in error >>> message spelling in the plpython regression tests on a Fedora 13 box >>> (python 2.6.4). Several buildfarm critters don't look too happy either. > >> Fixed. (Well, some of it. We'll see ...) > > Core dump is still there. It appears to be a python assertion failure. > I installed python's debuginfo and got this backtrace: > > Program terminated with signal 6, Aborted. > #0 0x00000032a36328f5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); > Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.2-6.fc12.x86_64 krb5-libs-1.7.1-17.fc13.x86_64 libcom_err-1.41.10-7.fc13.x86_64libselinux-2.0.94-2.fc13.x86_64 openssl-1.0.0c-1.fc13.x86_64 zlib-1.2.3-23.fc12.x86_64 > (gdb) bt > #0 0x00000032a36328f5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x00000032a36340d5 in abort () at abort.c:92 > #2 0x00000032a362b8b5 in __assert_fail (assertion=0x32a5b46391 "gc->gc.gc_refs != 0", file=<value optimized out>, line=277,function=<value optimized out>) > at assert.c:81 > #3 0x00000032a5b0853e in visit_decref (op=<module at remote 0x7f11c3666d38>, data=<value optimized out>) at Modules/gcmodule.c:277 > #4 0x00000032a5a7cbd9 in dict_traverse (op= > {'info': <built-in function info>, 'notice': <built-in function notice>, 'Fatal': <type at remote 0x1bba7e0>, 'log':<built-in function log>, 'prepare': <built-in function prepare>, 'spiexceptions': <module at remote 0x7f11c3666d38>,'SPIError': <type at remote 0x1bbacc0>, 'Error': <type at remote 0x1bba300>, 'execute': <built-in functionexecute>, '__package__': None, 'quote_ident': <built-in function quote_ident>, 'warning': <built-in function warning>,'subtransaction': <built-in function subtransaction>, 'quote_literal': <built-in function quote_literal>, 'quote_nullable':<built-in function quote_nullable>, 'error': <built-in function error>, 'debug': <built-in function debug>,'__name__': 'plpy', 'fatal': <built-in function fatal>, '__doc__': None}, visit=0x32a5b084c0 <visit_decref>, arg=0x0) > at Objects/dictobject.c:2003 > [...] > #24 0x00000032a5af22c4 in PyImport_ImportModuleLevel (name=0x7f11c40c2084 "string", globals= > > Don't know python enough to do anything useful with this, but the > reference to "gc_refs" sure makes it look like something is dropping the > ball on when to do INCREF/DECREF. That's strange, the error occurs while trying to import the "string" module. But the error itself seems to be caused by trying to unref the spiexceptions module (showing up here as <module at remote 0x7f11c3666d38>). Apparently adding spiexceptions as an object to the plpy module is not done exactly right. I'll try to reproduce it in my environment. Cheers, Jan