I wrote:
> so how come this test case doesn't crash for everybody?
I traced through this, and what I see is that the error information
constructed at the time of the inner ereport includes
0x1f98528 "invalid transaction termination", detail = 0x0, detail_log =
0x0, hint = 0x0, context =
0x1f98598 "PL/Python anonymous code block\nSQL statement \"DO LANGUAGE plpythonu $x$ plpy.commit() $x$\"\nPL/Python
function\"(null)\"", message_id =
0xa0fc50 "invalid transaction termination", schema_name = 0x0,
So, in fact, we *are* passing a null pointer to sprintf here.
Apparently, none of the machines in the buildfarm crash on that,
or at least none of the ones building plpython do, which is
pretty troubling from a test coverage standpoint. I suggest that
it might be a good idea to insert an "Assert(strvalue != NULL)"
in src/port/snprintf.c, approx. line 748, so that at least the
machines using that fallback implementation are guaranteed to
whine about this type of mistake.
The reason we don't see this obviously-bogus output in the test
results is that when control exits the outer Python function,
the inner error result is thrown away during
PLy_abort_open_subtransactions, and then we generate an all-new error
report with "PLy_elog(ERROR, NULL)". That contains only Python's
own traceback plus the output from a (duplicate) call of
plpython_error_callback, which now gets the right answer because
PLy_execution_contexts is now pointing at the outer function's
context.
So I'm still thinking I can construct a test case in which plpython
outputs a clearly-wrong context stack, but it will have to involve
elog(NOTICE) rather than ERROR. Will work on that.
regards, tom lane