Server crashes involving plan_cache_mode #410
Description
What happens?
Server crashes when executing the script below involving plan_cache_mode
The repro below is somewhat minimal that removing any query in it doesn't crash
To Reproduce
SET duckdb.force_execution = ON;
CREATE TABLE t (a INT);
PREPARE f (INT) AS SELECT count(*) FROM t WHERE a = $1;
SET plan_cache_mode TO force_generic_plan;
EXPLAIN (COSTS OFF) EXECUTE f(2);
EXECUTE f(1); -- crashbacktrace
#0 0x0000aaaaea314ba4 in heap_compute_data_size (tupleDesc=0xaaab19ca7a48, values=0xaaab19ca7ba0, isnull=0xaaab19ca7bb0) at heaptuple.c:235
#1 0x0000aaaaea317e64 in heap_form_minimal_tuple (tupleDescriptor=0xaaab19ca7a48, values=0xaaab19ca7ba0, isnull=0xaaab19ca7bb0) at heaptuple.c:1492
#2 0x0000aaaaea60a4a8 in tts_virtual_copy_minimal_tuple (slot=0xaaab19ca7b58) at execTuples.c:305
#3 0x0000aaaaeab38640 in ExecCopySlotMinimalTuple (slot=0xaaab19ca7b58) at ../../../../src/include/executor/tuptable.h:494
#4 0x0000aaaaeab39220 in tuplestore_puttupleslot (state=0xaaab19afa260, slot=0xaaab19ca7b58) at tuplestore.c:717
#5 0x0000aaaaea665240 in tstoreReceiveSlot_notoast (slot=0xaaab19ca7b58, self=0xaaab19a3f308) at tstoreReceiver.c:126
#6 0x0000aaaaea5faf00 in ExecutePlan (estate=0xaaab19ca7510, planstate=0xaaab19ca7758, use_parallel_mode=false, operation=CMD_SELECT, sendTuples=true, numberTuples=0, direction=ForwardScanDirection, dest=0xaaab19a3f308, execute_once=true) at execMain.c:1679
#7 0x0000aaaaea5f8858 in standard_ExecutorRun (queryDesc=0xaaab19cafa80, direction=ForwardScanDirection, count=0, execute_once=true) at execMain.c:365
#8 0x0000aaaaea5f8620 in ExecutorRun (queryDesc=0xaaab19cafa80, direction=ForwardScanDirection, count=0, execute_once=true) at execMain.c:306
#9 0x0000aaaaea8d79ac in PortalRunSelect (portal=0xaaab19a91ee0, forward=true, count=0, dest=0xaaab19a3f308) at pquery.c:924
#10 0x0000aaaaea8d75e8 in PortalRun (portal=0xaaab19a91ee0, count=9223372036854775807, isTopLevel=false, run_once=true, dest=0xaaab19a3f308, altdest=0xaaab19a3f308, qc=0xffffc4c16278) at pquery.c:768
#11 0x0000aaaaea5706c8 in ExecuteQuery (pstate=0xaaab19a3f398, stmt=0xaaab199f5310, intoClause=0x0, params=0x0, dest=0xaaab19a3f308, qc=0xffffc4c16278) at prepare.c:255
#12 0x0000aaaaea8d9ed4 in standard_ProcessUtility (pstmt=0xaaab199f53c0, queryString=0xaaab199f48c0 "EXECUTE f(1);", readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0xaaab19a3f308, qc=0xffffc4c16278) at utility.c:750
#13 0x0000ffff8f39391c in DuckdbUtilityHook_Cpp (qc=0xffffc4c16278, dest=0xaaab19a3f308, query_env=0x0, params=0x0, context=PROCESS_UTILITY_TOPLEVEL, read_only_tree=false, query_string=0xaaab199f48c0 "EXECUTE f(1);", pstmt=0xaaab199f53c0) at src/pgduckdb_hooks.cpp:220
#14 pgduckdb::__CPPFunctionGuard__<void (*)(PlannedStmt*, char const*, bool, ProcessUtilityContext, ParamListInfoData*, QueryEnvironment*, _DestReceiver*, QueryCompletion*), DuckdbUtilityHook_Cpp, PlannedStmt*, char const*, bool, ProcessUtilityContext, ParamListInfoData*, QueryEnvironment*, _DestReceiver*, QueryCompletion*> (func_name=0xffff8f3cd3c8 "DuckdbUtilityHook") at src/pgduckdb_hooks.cpp:229
#15 0x0000aaaaea8d9860 in ProcessUtility (pstmt=0xaaab199f53c0, queryString=0xaaab199f48c0 "EXECUTE f(1);", readOnlyTree=false, context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0xaaab19a3f308, qc=0xffffc4c16278) at utility.c:519
#16 0x0000aaaaea8d7fc0 in PortalRunUtility (portal=0xaaab19a91dd0, pstmt=0xaaab199f53c0, isTopLevel=true, setHoldSnapshot=true, dest=0xaaab19a3f308, qc=0xffffc4c16278) at pquery.c:1158
#17 0x0000aaaaea8d7cdc in FillPortalStore (portal=0xaaab19a91dd0, isTopLevel=true) at pquery.c:1031
#18 0x0000aaaaea8d75d4 in PortalRun (portal=0xaaab19a91dd0, count=9223372036854775807, isTopLevel=true, run_once=true, dest=0xaaab199f5780, altdest=0xaaab199f5780, qc=0xffffc4c16508) at pquery.c:763
#19 0x0000aaaaea8ce9ec in exec_simple_query (query_string=0xaaab199f48c0 "EXECUTE f(1);") at postgres.c:1278
#20 0x0000aaaaea8d44c0 in PostgresMain (dbname=0xaaab19a4dc88 "postgres", username=0xaaab19a4dc68 "postgres") at postgres.c:4767
#21 0x0000aaaaea8ca5d0 in BackendMain (startup_data=0xffffc4c167e0 "", startup_data_len=4) at backend_startup.c:105
#22 0x0000aaaaea7c8de4 in postmaster_child_launch (child_type=B_BACKEND, startup_data=0xffffc4c167e0 "", startup_data_len=4, client_sock=0xffffc4c16848) at launch_backend.c:277
#23 0x0000aaaaea7cfea8 in BackendStartup (client_sock=0xffffc4c16848) at postmaster.c:3593
#24 0x0000aaaaea7cc580 in ServerLoop () at postmaster.c:1674
#25 0x0000aaaaea7cbd64 in PostmasterMain (argc=3, argv=0xaaab199eee50) at postmaster.c:1372
#26 0x0000aaaaea682dac in main (argc=3, argv=0xaaab199eee50) at main.c:197OS:
Linux
pg_duckdb Version:
0.1.0
Postgres Version:
17.0
Hardware:
No response
Full Name:
Cheng Chen
Affiliation:
Mooncake Labs
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a stable release
Did you include all relevant data sets for reproducing the issue?
Not applicable - the reproduction does not require a data set
Did you include all code required to reproduce the issue?
- Yes, I have
Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?
- Yes, I have