Re: BUG #19653: "variable not found in subplan target list" during planning with parallel parameterized nested loop,

пт, 4 сент. 2026 г. в 19:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > A query using a partitioned left/right join split, with
> > `enable_partitionwise_join`, parallel settings, and `GROUP BY ROLLUP`
> fails
> > at planning time with:
> > ERROR: variable not found in subplan target list
>
> Fascinating. For me, this fails *only* in v18, not earlier or later
> branches. That's not a usual pattern for our bugs ...
>
> Will look closer in a bit, if nobody beats me to it.
>
> regards, tom lane
>
>
>
I tested the SQL from this report with the same setup pattern on these
branches:

- REL_18_STABLE: fails
- master: does not fail
- REL_17_STABLE: does not fail

On REL_18_STABLE, planning fails with:

ERROR: variable not found in subplan target list
LOCATION: fix_upper_expr_mutator, setrefs.c:3314

This failure is still reproducible with max_parallel_workers_per_gather = 0.
So in this repro, parallel Gather is not required.

In the same repro, these control variants succeed:

- enable_partitionwise_join = off
- ANALYZE on both joined sides (planner switches to hash join)

Observed plan difference in this test case:

- in REL_18_STABLE failing shape, the failing path reaches setrefs with
a NestLoopParam mapping failure
- in master and REL_17_STABLE runs, the observed plan includes outer scan
output with m_l.tsvec, and planning completes

In this code base snapshot, commit 014f9a831a3 ("Don't reset the pathlist
of partitioned joinrels") is present on master and absent on
REL_18_STABLE.

I ran gdb on REL_18_STABLE to confirm where the error is raised.
The observed stack at failure is:

set_append_references
-> set_plan_refs
-> set_join_references
-> fix_upper_expr (NRM_SUBSET for NestLoopParam)
-> fix_upper_expr_mutator

This confirms a planning-time mapping failure while processing
NestLoopParam expressions.

I then tested one code change in create_nestloop_plan:

- when a Var NestLoopParam is not present in outer_plan->targetlist,
add that Var to outer_tlist (same handling pattern already used there
for PHV NestLoopParams)

Observed result with that change:

- REL_18_STABLE no longer throws XX000 on the reporter query
- the query returns the expected two rows
- EXPLAIN for that shape shows the needed outer value emitted by outer scan

--
Regards,
Rachitskiy Andrey