Re: BUG #19804: "variable not found in subplan target list", DISTINCT agg over Gather`

PG Bug reporting form <noreply(at)postgresql(dot)org> 于2026年10月29日周四 18:43写道：

> This query fails at plan time with an internal error:
>
> CREATE TABLE a (x int);
> CREATE TABLE b (id int, y int) PARTITION BY RANGE (id);
> CREATE TABLE b1 PARTITION OF b FOR VALUES FROM (MINVALUE) TO (0);
> CREATE TABLE b2 PARTITION OF b FOR VALUES FROM (0) TO (MAXVALUE);
> ANALYZE;
> SET parallel_setup_cost = 0;
> SET parallel_tuple_cost = 0;
> SELECT count(DISTINCT a.x + 1)
> FROM a JOIN b TABLESAMPLE BERNOULLI (100) ON b.y = a.x + 1
> GROUP BY b.y * 2;
>
> ERROR: XX000: variable not found in subplan target list
> LOCATION: fix_upper_expr_mutator, setrefs.c:3314 (18.6)

I investigated this with gdb. The failure appears to involve the
computability check introduced by 9f954177.

The Gather and its NestLoop subplan initially both have the targetlist:

[b.y * 2, a.x]

When preparing the sort for the presorted aggregate, the first pathkey
matches the existing expression b.y * 2. The second pathkey refers to
the join EC {b.y, a.x + 1}, but neither member matches an existing
targetlist entry.

prepare_sort_from_pathkeys() therefore calls
find_computable_ec_member(). Its pull_var_clause() call extracts [b.y,
a.x] from the targetlist, so the first EC member, b.y, passes the
computability check.

prepare_sort_from_pathkeys() then adds b.y as a resjunk column
directly to the Gather's targetlist, since Gather is
projection-capable.
However, the NestLoop below it still outputs only [b.y * 2, a.x]. The
Gather cannot retrieve b.y from those output columns, and
set_upper_references() consequently fails.

Without TABLESAMPLE, the chosen plan has the Sort directly above the
NestLoop, with the Gather below the join. In that case, adding b.y to
the NestLoop's targetlist works because b.y is available from its join
input.

The distinction seems to be that, for Gather, a Var occurring inside
an existing target expression is not necessarily available to its
projection: that expression may already have been computed by the
child.

As an experiment, restoring the old is_exprlist_member() check makes
this query work, since it rejects b.y and selects a.x + 1 instead.
However, that also breaks the regression test added by 9f954177, so
simply reverting the change is not sufficient.

I do not have a proposed fix yet, but wanted to share these findings.

--
Thanks,
Tender Wang