BUG #18070: Assertion failed when processing error from plpy's iterator

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: exclusion(at)gmail(dot)com
Subject: BUG #18070: Assertion failed when processing error from plpy's iterator
Date: 2023-08-25 14:00:01
Message-ID: 18070-ab9c171cbf4ebb0f@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 18070
Logged by: Alexander Lakhin
Email address: exclusion(at)gmail(dot)com
PostgreSQL version: 16beta3
Operating system: Ubuntu 22.04
Description:

The following script:
CREATE EXTENSION plpython3u;

CREATE FUNCTION pyfunc() RETURNS SETOF text AS $$
plan = plpy.prepare("SELECT * FROM pyfunc()", ["text"])
for row in plpy.cursor(plan, ["w"]):
yield row[0]
$$ LANGUAGE plpython3u;

SELECT pyfunc();

triggers the assertion failure:
TRAP: failed Assert("detail == NULL"), File: "plpy_elog.c", Line: 107, PID:
784729

Core was generated by `postgres: law regression [local] SELECT
'.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/784729' in core file too small.
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140508500382656)
at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140508500382656)
at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140508500382656) at
./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140508500382656, signo=signo(at)entry=6) at
./nptl/pthread_kill.c:89
#3 0x00007fcaae523476 in __GI_raise (sig=sig(at)entry=6) at
../sysdeps/posix/raise.c:26
#4 0x00007fcaae5097f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x000055e42de8b7ab in ExceptionalCondition (conditionName=0x7fcaa360d2fc
"detail == NULL",
fileName=0x7fcaa360d2f0 "plpy_elog.c", lineNumber=107) at assert.c:66
#6 0x00007fcaa35fd766 in PLy_elog_impl (elevel=21,
fmt=0x7fcaa360d830 "error fetching next item from iterator") at
plpy_elog.c:107
#7 0x00007fcaa35ff443 in PLy_exec_function (fcinfo=0x55e432b63818,
proc=0x55e42f100b18)
at plpy_exec.c:168
#8 0x00007fcaa36025df in plpython3_call_handler (fcinfo=0x55e432b63818) at
plpy_main.c:245
#9 0x000055e42d9f81e5 in ExecMakeTableFunctionResult
(setexpr=0x55e432b5fd60, econtext=0x55e432b5fc30,
argContext=0x55e432b63700, expectedDesc=0x55e432b5fe20,
randomAccess=true) at execSRF.c:235
#10 0x000055e42da1506e in FunctionNext (node=0x55e432b5fa20) at
nodeFunctionscan.c:95
#11 0x000055e42d9f9cc6 in ExecScanFetch (node=0x55e432b5fa20,
accessMtd=0x55e42da14fb8 <FunctionNext>,
recheckMtd=0x55e42da153bf <FunctionRecheck>) at execScan.c:132
#12 0x000055e42d9f9d3f in ExecScan (node=0x55e432b5fa20,
accessMtd=0x55e42da14fb8 <FunctionNext>,
recheckMtd=0x55e42da153bf <FunctionRecheck>) at execScan.c:181
#13 0x000055e42da15418 in ExecFunctionScan (pstate=0x55e432b5fa20) at
nodeFunctionscan.c:270
#14 0x000055e42d9f5689 in ExecProcNodeFirst (node=0x55e432b5fa20) at
execProcnode.c:464
#15 0x000055e42d9e8716 in ExecProcNode (node=0x55e432b5fa20)
at ../../../src/include/executor/executor.h:273
#16 0x000055e42d9eb6ce in ExecutePlan (estate=0x55e432b5f7f8,
planstate=0x55e432b5fa20,
use_parallel_mode=false, operation=CMD_SELECT, sendTuples=true,
numberTuples=1,
direction=ForwardScanDirection, dest=0x55e42e2190c0 <spi_printtupDR>,
execute_once=false)
at execMain.c:1670
...

(gdb) frame 6
#6 0x00007fcaa35fd766 in PLy_elog_impl (elevel=21,
fmt=0x7fcaa360d830 "error fetching next item from iterator") at
plpy_elog.c:107
107 Assert(detail == NULL);
(gdb) p xmsg
$1 = 0x55e432b68300 "spiexceptions.StatementTooComplex: error fetching next
item from iterator"
(gdb) p detail
$2 = 0x7fcaa2d50a70 "spiexceptions.StatementTooComplex: stack depth limit
exceeded"

Without asserts enabled, I get:
ERROR: error fetching next item from iterator
DETAIL: spiexceptions.StatementTooComplex: error fetching next item from
iterator
HINT: Increase the configuration parameter "max_stack_depth" (currently
2048kB), after ensuring the platform's stack depth limit is adequate.
CONTEXT: Traceback (most recent call last):
PL/Python function "pyfunc"

It looks like the following coding in PLy_elog_impl():
/* Since we have a format string, we cannot have a SPI detail. */
Assert(detail == NULL);

/* If there's an exception message, it goes in the detail. */
if (xmsg)
detail = xmsg;

doesn't expect to process a call PLy_elog(LEVEL, "message") when some (SPI)
error occurred before the call.

Reproduced on REL_11_STABLE (with plpython2u) .. master.

Apparently, this coding exists since 2bd78eb8d.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Joe Conway 2023-08-27 13:41:01 Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG
Previous Message PG Bug reporting form 2023-08-25 06:40:12 BUG #18069: pg_is_in_recovery() is false but recovery is not yet completed(i.e. recovery.signal is present)