PG Bug reporting form <noreply@postgresql.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
