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

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