Re: BUG #19579: Wrong results regression

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: leis(at)in(dot)tum(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19579: Wrong results regression
Date: 2026-07-27 12:38:31
Message-ID: CAJTYsWX4R5Zbyq87FPTDwOXczb9jXFSwxVtPP74=fR6Xoyi5jA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Mon, 27 Jul 2026 at 15:53, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 19579
> Logged by: Viktor Leis
> Email address: leis(at)in(dot)tum(dot)de
> PostgreSQL version: 19beta2
> Operating system: Ubuntu 26.04 LTS
> Description:
>
> Hi,
>
> The following self-contained query returns rows on current master and on
> 19beta2, but should return nothing. PostgreSQL 18 and earlier are
> unaffected.
>
> select * from
> (select 0 as c0 from
> (select t1.c0 from
> (select null::int as c0 from ((select 1) union all (select 2))
> t0)
> t1
> full join (select 1 as c1 where false) t2 on true) t3
> where c0 <> 7) t4
> cross join (select * from (values (0::bigint)) v(x)
> where now() is not null) t5;
>
> c0 | x
> ----+---
> 0 | 0
> 0 | 0
> (2 rows)
>
> t1.c0 is a plain NULL::integer, so "c0 <> 7" is NULL for every row and
> nothing should survive it. EXPLAIN (VERBOSE, COSTS OFF) shows that the
> filter is simply gone:
>
> Result
> Output: 0, '0'::bigint
> -> Append
> -> Result
> One-Time Filter: (now() IS NOT NULL)
> -> Result
> One-Time Filter: (now() IS NOT NULL)
>
> Bisection points to commit f2bae51dfd5 ("Keep track of what RTIs a Result
> node is scanning", 2025-09-23).
>

Thanks for the report and analysis.

I spent some time on this one. If I'm reading it right, the bisect to
f2bae51dfd5 seems to point at create_gating_plan(): when it stacks a
gating Result over an existing Result, it now absorbs the child
unconditionally, whereas before it only did that for a "trivial" child
(no subplan and no resconstantqual). So when the child carries a
one-time filter, that filter looks like it just gets dropped, which would
explain the missing "NULL <> 7" gate in the reported plan.

Restoring the old triviality guard (keep the child as our subplan when it
has a resconstantqual or a subplan) makes the query return no rows again
for me, and still keeps the relids/result_type attribution for the
trivial case.

Regards,
Ayush

Attachment Content-Type Size
v1-0001-Fix-create_gating_plan-dropping-a-child-Result-s-.patch application/octet-stream 5.6 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-07-27 16:18:59 BUG #19582: Query fails on mixed IPv4 IPv6 data when index added
Previous Message Tom Lane 2026-07-27 12:32:34 Re: BUG #19581: Non-UTF8-encoded text in log file