Marina Polyakova <m.polyak...@postgrespro.ru> writes: > On 14-02-2018 3:43, Peter Eisentraut wrote: >> OK, can you get some kind of stack trace or other debugging >> information?
> I got this backtrace from gdb: Hmm, so the only question in my mind is how did this ever work for anyone? The basic problem here is that, instead of using the ErrorContextCallback.arg field provided for the purpose, plpython_error_callback is using PLy_current_execution_context() to try to identify the context it's supposed to report on. In the example, that points to the context associated with the inner DO block, not with the outer procedure. That context looks like it should reliably have curr_proc->proname == NULL, so how come this test case doesn't crash for everybody? In any case the expected output for the transaction_test4 case is obviously wrong. Rather than reporting the transaction_test4 function and then the inner DO block, it's reporting 2 levels of transaction_test4. That seems to trace directly to both levels of error context callback looking at the same execution context. I think we need to fix the error callback code so that it uses the "arg" field to find the relevant procedure, and that that's a back-patchable fix, because nested plpython functions would show this up as wrong in any case. That would also let us undo the not-terribly-safe practice of having code between the PLy_push_execution_context call and the PG_TRY that is supposed to ensure the context gets popped again. While I'm bitching ... I wonder how long it's been since the comment for PLy_procedure_name() had anything to do with its actual behavior. regards, tom lane