From: Tom Lane <tgl@sss.pgh.pa.us>
To: 10215501441@stu.ecnu.edu.cn
cc: Richard Guo <guofenglinux@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19653: "variable not found in subplan target list" during
 planning with parallel parameterized nested loop,
In-reply-to: <1564958.1788530496@sss.pgh.pa.us>
References: <19653-9352cc6ba17b662f@postgresql.org>
 <1564958.1788530496@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 04 Sep 2026 10:01:36 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1570203.1788535631.1@sss.pgh.pa.us>
Date: Fri, 04 Sep 2026 11:27:11 -0400
Message-ID: <1570204.1788535631@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1570204.1788535631%40sss.pgh.pa.us>
Precedence: bulk

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

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@postgresql.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@postgresql.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