Re: BUG #19766: Assert in shm_toc_insert: EXPLAIN ANALYZE of a SubPlan shared by Parallel Append children

Hello,

I ran into the same assertion independently while fuzzing an
assert-enabled master build, and can add one data point: the shared
SubPlan does not need a partitioned table. An inheritance parent and
child give the same Parallel Append and the same crash, with default
settings and empty tables:

CREATE TABLE ip (a int);
CREATE TABLE ic () INHERITS (ip);
CREATE TABLE s (b int);
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY OFF, BUFFERS OFF)
SELECT * FROM ip WHERE a NOT IN (SELECT 1 FROM s, s s2);

TRAP: failed Assert("toc->toc_entry[i].key != key"), File: "shm_toc.c", Line: 190
shm_toc_insert
ExecMaterialInitializeDSM

The plan is Gather -> Parallel Append -> Parallel Seq Scan on ic and on
ip, both with the filter NOT (ANY (a = (SubPlan any_1).col1)), as in
your partitioned case. Your ORDER BY b, b + 1 query on these tables
fails the same assertion in ExecSortInitializeDSM.

The fuzzer also reached it in ExecAggInitializeDSM and
ExecSortInitializeDSM with a larger query whose Parallel Append is over
an inheritance parent and child sharing a hashed SubPlan. The
ExecSortInitializeDSM case there did not need debug_parallel_query:
work_mem = '64kB' and cpu_tuple_cost = 10 were enough.

Tested on master at 7787aec (--enable-cassert --enable-debug, Linux
x86_64; the build carries an unrelated one-line parser patch).

Regards,
Bhuvan Chilukuti
________________________________
From: PG Bug reporting form <noreply(at)postgresql(dot)org>
Sent: Friday, October 16, 2026 8:54 PM
To: pgsql-bugs(at)lists(dot)postgresql(dot)org <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Cc: alpkeles99(at)gmail(dot)com <alpkeles99(at)gmail(dot)com>
Subject: BUG #19766: Assert in shm_toc_insert: EXPLAIN ANALYZE of a SubPlan shared by Parallel Append children

[You don't often get email from noreply(at)postgresql(dot)org(dot) Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

The following bug has been logged on the website:

Bug reference: 19766
Logged by: Alperen Keles
Email address: alpkeles99(at)gmail(dot)com
PostgreSQL version: 19rc1
Operating system: Ubuntu 24.04 x86_64 (also macOS 26 arm64)
Description:

Hello,

On an assert-enabled master, this crashes the backend with default
settings and empty tables:

CREATE TABLE p (a int) PARTITION BY LIST (a);
CREATE TABLE p1 PARTITION OF p FOR VALUES IN (1);
CREATE TABLE p2 PARTITION OF p FOR VALUES IN (2);
CREATE TABLE s (b int);
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY OFF, BUFFERS OFF)
SELECT * FROM p WHERE a NOT IN (SELECT 1 FROM s, s s2);

TRAP: failed Assert("toc->toc_entry[i].key != key"), File: "shm_toc.c",
Line: 190

shm_toc_insert
ExecMaterialInitializeDSM nodeMaterial.c:440
ExecParallelInitializeDSM execParallel.c:596
planstate_walk_subplans nodeFuncs.c:4838
planstate_walk_members
planstate_tree_walker_impl (the Parallel Append)
ExecParallelInitializeDSM execParallel.c:602
ExecInitParallelPlan
ExecGather

The query without ANALYZE runs normally. The plan is Gather ->
Parallel Append -> two Parallel Seq Scans, each with the filter
"NOT (ANY (a = (SubPlan any_1).col1))"; the SubPlan is Materialize ->
Nested Loop -> (Seq Scan, Materialize -> Seq Scan).

The SubPlan referenced by both partitions' quals has a single PlanState,
but planstate_tree_walker() visits the subPlan list of each child, so
ExecParallelInitializeDSM() reaches the SubPlan's nodes once per
partition and inserts the same plan_node_id into the TOC twice. Since
a241bc4fede ("Show Material node Maximum Storage for parallel workers")
Material is one of the nodes that put an entry there, which makes this
reachable with default settings.

The double visit itself is older. On REL_19_STABLE (19rc1), and on
a241bc4fede's parent, the same assertion fails when the shared SubPlan
contains another node with parallel instrumentation, with the same
tables:

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY OFF, BUFFERS OFF)
SELECT * FROM p WHERE a > ALL (SELECT b FROM s ORDER BY b, b + 1);
-> TRAP ... in ExecSortInitializeDSM

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY OFF, BUFFERS OFF)
SELECT * FROM p WHERE a > ALL (SELECT b FROM s GROUP BY b);
-> TRAP ... in ExecAggInitializeDSM

(On REL_19_STABLE the failing assertion reads
Assert("vtoc->toc_entry[i].key != key"), shm_toc.c:193.) I got it from
ExecHashInitializeDSM, ExecMemoizeInitializeDSM and
ExecIncrementalSortInitializeDSM in the same way. The duplicate-key
assertion is 43222b8e53f, so REL_18_STABLE and older don't trap.

Versions tested (Ubuntu 24.04, x86_64, gcc 13.3, --enable-cassert
--enable-debug, CFLAGS=-O2, dynamic_shared_memory_type = mmap; builds
from 2026-10-16):
- master a261fc2b722: all three queries crash (the first one also on
macOS 26 arm64, master 158b6d5109f)
- a241bc4fede: the first query crashes; its parent c6b8af429b3 runs it
but crashes on the other two
- REL_19_STABLE 1212d5d33b1 (19rc1): the first query runs, the other
two crash
- REL_18_STABLE dfbc1507cdb (18.6), REL_14_STABLE 14904052e65 (14.24):
no crash

Found with a query fuzzer.

Regards,
Alperen Keles