Fix broken logic for reporting PL/Python function names in errcontext. plpython_error_callback() reported the name of the function associated with the topmost PL/Python execution context. This was not merely wrong if there were nested PL/Python contexts, but it risked a core dump if the topmost one is an inline code block rather than a named function. That will have proname = NULL, and so we were passing a NULL pointer to snprintf("%s"). It seems that none of the PL/Python-testing machines in the buildfarm will dump core for that, but some platforms do, as reported by Marina Polyakova.
Investigation finds that there actually is an existing regression test that used to prove that the behavior was wrong, though apparently no one had noticed that it was printing the wrong function name. It stopped showing the problem in 9.6 when we adjusted psql to not print CONTEXT by default for NOTICE messages. The problem is masked (if your platform avoids the core dump) in error cases, because PL/Python will throw away the originally generated error info in favor of a new traceback produced at the outer level. Repair by using ErrorContextCallback.arg to pass the correct context to the error callback. Add a regression test illustrating correct behavior. Back-patch to all supported branches, since they're all broken this way. Discussion: https://postgr.es/m/156b989dbc6fe7c4d3223cf51da61...@postgrespro.ru Branch ------ REL9_5_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/db1c597f3c331f57201a6fbfab72b93fd98f9945 Modified Files -------------- src/pl/plpython/expected/plpython_error.out | 23 ++++++++++ src/pl/plpython/expected/plpython_error_0.out | 23 ++++++++++ src/pl/plpython/expected/plpython_error_5.out | 23 ++++++++++ .../plpython/expected/plpython_subtransaction.out | 2 +- src/pl/plpython/plpy_main.c | 52 +++++++++++----------- src/pl/plpython/plpy_procedure.c | 4 +- src/pl/plpython/sql/plpython_error.sql | 16 +++++++ 7 files changed, 113 insertions(+), 30 deletions(-)