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

I wrote:
> 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 ...

A bit of quality time with "git bisect" found that the misbehavior
started at

cc5d98525d43c22b98f360ef0f2c8d7dc57f04dc is the first bad commit
commit cc5d98525d43c22b98f360ef0f2c8d7dc57f04dc
Author: Richard Guo <rguo(at)postgresql(dot)org>
Date: Thu Mar 13 16:36:03 2025 +0900

Fix incorrect handling of subquery pullup

and was fixed by

014f9a831a320666bf2195949f41710f970c54ad is the first new commit
commit 014f9a831a320666bf2195949f41710f970c54ad
Author: Robert Haas <rhaas(at)postgresql(dot)org>
Date: Fri Dec 5 11:05:12 2025 -0500

Don't reset the pathlist of partitioned joinrels.

The proximate cause of the failure is that we have a NestLoopParam
containing a Var, which we need to find in the tlist of the nestloop's
outer relation, but what is in the tlist is a PlaceHolderVar wrapping
that Var. So it's possible to see some connection to cc5d98525, but
it seems entirely accidental that 014f9a831 fixed it. I bet there
are related cases that are still broken.

regards, tom lane