Kurt Roeckx wrote: > #3 0x00000000006c8033 in MemoryContextAlloc (context=0x0, size=112) > at mcxt.c:507 > #4 0x00000000006abe82 in CopyErrorData () at elog.c:1082 > #5 0x00002b41ea61a755 in PLy_spi_execute_plan (ob=<value optimized out>, > list=<value optimized out>, limit=<value optimized out>) at > plpython.c:2587
It's calling CopyErrorData with CurrentMemoryContext pointing to NULL, which is not impossible since the GCC-inlined version of MemoryContextSwitchTo does not check that it wasn't (the other version does -- should we fix that?). The question is why is that memory context set to NULL. The code looks like this: PLy_spi_execute_plan( ... ) { MemoryContext oldcontext; ... oldcontext = CurrentMemoryContext; PG_TRY(); { ... } PG_CATCH(); { MemoryContextSwitchTo(oldcontext); CopyErrorData(); ... } This has been like this for quite a while, which I find surprising because I got scolded for a similar coding pattern awhile back. I think I found that the variable was reversed to the value it had on entering the block by the longjmp call. (IIRC Tom complained because his compiler threw a "variable might be clobbered by longjmp" warning). We at Command Prompt also had a similar case on the then-proprietary Replicator code. I think a simplistic solution is to declare the variable volatile. Would you test that and report back? Thanks. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers