agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedBUG #19579: Wrong results regression
7+ messages / 4 participants
[nested] [flat]
* BUG #19579: Wrong results regression
@ 2026-07-25 07:19 PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: PG Bug reporting form @ 2026-07-25 07:19 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: leis@in.tum.de
The following bug has been logged on the website:
Bug reference: 19579
Logged by: Viktor Leis
Email address: leis@in.tum.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).
Best regards,
Viktor Leis
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: BUG #19579: Wrong results regression
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
@ 2026-07-27 12:38 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-28 00:38 ` Re: BUG #19579: Wrong results regression David Rowley <dgrowleyml@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Ayush Tiwari @ 2026-07-27 12:38 UTC (permalink / raw)
To: leis@in.tum.de; pgsql-bugs@lists.postgresql.org
Hi,
On Mon, 27 Jul 2026 at 15:53, PG Bug reporting form <noreply@postgresql.org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19579
> Logged by: Viktor Leis
> Email address: leis@in.tum.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
Attachments:
[application/octet-stream] v1-0001-Fix-create_gating_plan-dropping-a-child-Result-s-.patch (5.6K, ../../CAJTYsWX4R5Zbyq87FPTDwOXczb9jXFSwxVtPP74=fR6Xoyi5jA@mail.gmail.com/3-v1-0001-Fix-create_gating_plan-dropping-a-child-Result-s-.patch)
download | inline diff:
From cc1bf5e2791f73e950428311e48c203060d19ec8 Mon Sep 17 00:00:00 2001
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Mon, 27 Jul 2026 12:27:36 +0000
Subject: [PATCH v1] Fix create_gating_plan() dropping a child Result's
one-time filter
Commit f2bae51dfd5 refactored create_gating_plan(). When it places a
gating Result node atop an existing Result, it tries to avoid stacking
two Result nodes by absorbing the child. The refactor began doing this
unconditionally for any Result child, whereas the previous code only
discarded the child when it was trivial, i.e. it had neither a subplan
nor a resconstantqual.
As a result, when the child Result carried a one-time filter
(resconstantqual), that filter was silently discarded, producing wrong
query results. For example, a pseudoconstant qual such as "c0 <> 7"
where c0 is a constant NULL becomes a one-time filter on a Result; if
another gating qual is applied on top, the original filter was lost and
rows that should have been rejected were returned.
Restore the original behavior: only absorb the child Result when it is
trivial, and otherwise keep it as the subplan so its resconstantqual
(or its own subplan) is preserved. This retains the relids/result_type
attribution added by f2bae51dfd5 for the trivial case, and respects the
invariant that a Result carries relids only when it has no subplan.
Add a regression test to join.sql.
Bug: #19579
Reported-by: Viktor Leis
---
src/backend/optimizer/plan/createplan.c | 15 ++++++++--
src/test/regress/expected/join.out | 37 +++++++++++++++++++++++++
src/test/regress/sql/join.sql | 20 +++++++++++++
3 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 2c696ea0268..945b7123f49 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -1040,14 +1040,23 @@ create_gating_plan(PlannerInfo *root, Path *path, Plan *plan,
* However, we preserve the set of relids that it purports to scan and
* attribute that to our replacement Result instead, and likewise for the
* result_type.)
+ *
+ * We can only do this when the input Result is itself trivial, i.e. it has
+ * no subplan of its own and no one-time filter. If it carries a
+ * resconstantqual (or a subplan), that work must be preserved, so we leave
+ * it in place as our subplan rather than discarding it.
*/
if (IsA(plan, Result))
{
Result *rplan = (Result *) plan;
- gplan->plan.lefttree = NULL;
- gplan->relids = rplan->relids;
- gplan->result_type = rplan->result_type;
+ if (rplan->plan.lefttree == NULL &&
+ rplan->resconstantqual == NULL)
+ {
+ gplan->plan.lefttree = NULL;
+ gplan->relids = rplan->relids;
+ gplan->result_type = rplan->result_type;
+ }
}
/*
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index 19e2cca548b..fb8de10ce63 100644
--- a/src/test/regress/expected/join.out
+++ b/src/test/regress/expected/join.out
@@ -6707,6 +6707,43 @@ select p.* from
One-Time Filter: false
(3 rows)
+-- bug #19579: a gating qual applied on top of a Result that already carries a
+-- one-time filter must not discard the lower filter
+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 rows)
+
+explain (costs off)
+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;
+ QUERY PLAN
+-----------------------------------------------------------
+ Result
+ -> Append
+ -> Result
+ One-Time Filter: (now() IS NOT NULL)
+ -> Result
+ One-Time Filter: (NULL::integer <> 7)
+ -> Result
+ One-Time Filter: (now() IS NOT NULL)
+ -> Result
+ One-Time Filter: (NULL::integer <> 7)
+(10 rows)
+
-- bug 5255: this is not optimizable by join removal
begin;
CREATE TEMP TABLE a (id int PRIMARY KEY);
diff --git a/src/test/regress/sql/join.sql b/src/test/regress/sql/join.sql
index 85aed7bf704..e1656eb364d 100644
--- a/src/test/regress/sql/join.sql
+++ b/src/test/regress/sql/join.sql
@@ -2487,6 +2487,26 @@ select p.* from
(parent p left join child c on (p.k = c.k)) join parent x on p.k = x.k
where p.k = 1 and p.k = 2;
+-- bug #19579: a gating qual applied on top of a Result that already carries a
+-- one-time filter must not discard the lower filter
+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;
+explain (costs off)
+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;
+
-- bug 5255: this is not optimizable by join removal
begin;
--
2.43.0
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: BUG #19579: Wrong results regression
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
@ 2026-07-28 00:38 ` David Rowley <dgrowleyml@gmail.com>
2026-07-28 05:48 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: David Rowley @ 2026-07-28 00:38 UTC (permalink / raw)
To: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; Robert Haas <robertmhaas@gmail.com>; +Cc: leis@in.tum.de; pgsql-bugs@lists.postgresql.org
On Tue, 28 Jul 2026 at 00:38, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
> 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.
I was looking at this last night and came to the same conclusion about
the mistake in create_gating_plan().
The test case can be simplified to:
select * from (
select c0 from (select null::int as c0 from ((select 1) union all
(select 2))) t1
full join (select 1) t2 on true
where c0 is not null
) t3 where now() is not null;
I'm not sure it's worth verifying the EXPLAIN output in the test as
the important part here is the result. It might not be inconceivable
that someone might want to chain the resconstantqual in the future
with:
gplan->resconstantqual = (Node *) list_concat((List *)
gplan->resconstantqual, (List *) rplan->resconstantqual);
and reduce to a single Result node.
I've included Robert here as I'm not all that certain why this change
was made. I suspect it was a misunderstanding of the comment "We might
have had a trivial Result plan already", where "trivial" is not well
defined. If that's the case, then I think the comments need work. Two
paragraphs seem a little excessive. Wouldn't the following suffice?
/*
* See if we can reduce down stacked Result nodes to a single node. This
* is only possible when the nested Result has no subplan and no gating
* qual. If we do remove the nested Result, we maintain the relids and
* result_type for EXPLAIN.
*/
David
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: BUG #19579: Wrong results regression
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-28 00:38 ` Re: BUG #19579: Wrong results regression David Rowley <dgrowleyml@gmail.com>
@ 2026-07-28 05:48 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-30 18:07 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-31 01:20 ` Re: BUG #19579: Wrong results regression David Rowley <dgrowleyml@gmail.com>
0 siblings, 2 replies; 7+ messages in thread
From: Ayush Tiwari @ 2026-07-28 05:48 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; leis@in.tum.de; pgsql-bugs@lists.postgresql.org
Hi,
On Tue, 28 Jul 2026 at 06:08, David Rowley <dgrowleyml@gmail.com> wrote:
> On Tue, 28 Jul 2026 at 00:38, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
> wrote:
> > 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.
>
> I was looking at this last night and came to the same conclusion about
> the mistake in create_gating_plan().
>
Thanks for the review!
> The test case can be simplified to:
>
> select * from (
> select c0 from (select null::int as c0 from ((select 1) union all
> (select 2))) t1
> full join (select 1) t2 on true
> where c0 is not null
> ) t3 where now() is not null;
>
> I'm not sure it's worth verifying the EXPLAIN output in the test as
> the important part here is the result. It might not be inconceivable
> that someone might want to chain the resconstantqual in the future
> with:
>
> gplan->resconstantqual = (Node *) list_concat((List *)
> gplan->resconstantqual, (List *) rplan->resconstantqual);
>
> and reduce to a single Result node.
>
Sounds good, I changed it to just the select statement.
> I've included Robert here as I'm not all that certain why this change
> was made. I suspect it was a misunderstanding of the comment "We might
> have had a trivial Result plan already", where "trivial" is not well
> defined. If that's the case, then I think the comments need work. Two
> paragraphs seem a little excessive. Wouldn't the following suffice?
>
> /*
> * See if we can reduce down stacked Result nodes to a single node. This
> * is only possible when the nested Result has no subplan and no gating
> * qual. If we do remove the nested Result, we maintain the relids and
> * result_type for EXPLAIN.
> */
>
Modified the comment as suggested above.
v2 patch attached.
Regards,
Ayush
Attachments:
[application/octet-stream] v2-0001-Fix-create_gating_plan-dropping-a-child-Result-s-.patch (4.3K, ../../CAJTYsWWEr3A=kJLnx477THv8usa7w4Ft9QCWiT_P1B-kYbq5cQ@mail.gmail.com/3-v2-0001-Fix-create_gating_plan-dropping-a-child-Result-s-.patch)
download | inline diff:
From aa4d8f39ee0022797d416da0008c2a28ef8fc92b Mon Sep 17 00:00:00 2001
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Tue, 28 Jul 2026 05:42:13 +0000
Subject: [PATCH v2] Fix create_gating_plan() dropping a child Result's
one-time filter
Commit f2bae51dfd5 refactored create_gating_plan(). When it places a
gating Result node atop an existing Result, it tries to avoid stacking
two Result nodes by absorbing the child. The refactor began doing this
unconditionally for any Result child, whereas the previous code only
discarded the child when it was trivial, i.e. it had neither a subplan
nor a resconstantqual.
As a result, when the child Result carried a one-time filter
(resconstantqual), that filter was silently discarded, producing wrong
query results. For example, a pseudoconstant qual such as "c0 IS NOT
NULL" where c0 is a constant NULL becomes a one-time filter on a Result;
if another gating qual is applied on top, the original filter was lost
and rows that should have been rejected were returned.
Restore the original behavior: only absorb the child Result when it is
trivial, and otherwise keep it as the subplan so its resconstantqual
(or its own subplan) is preserved. This retains the relids/result_type
attribution added by f2bae51dfd5 for the trivial case, and respects the
invariant that a Result carries relids only when it has no subplan.
Add a regression test to join.sql.
Bug: #19579
Reported-by: Viktor Leis
---
src/backend/optimizer/plan/createplan.c | 21 +++++++++++----------
src/test/regress/expected/join.out | 10 ++++++++++
src/test/regress/sql/join.sql | 7 +++++++
3 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 2c696ea0268..ab392ef60fe 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -1033,21 +1033,22 @@ create_gating_plan(PlannerInfo *root, Path *path, Plan *plan,
(Node *) gating_quals, plan);
/*
- * We might have had a trivial Result plan already. Stacking one Result
- * atop another is silly, so if that applies, just discard the input plan.
- * (We're assuming its targetlist is uninteresting; it should be either
- * the same as the result of build_path_tlist, or a simplified version.
- * However, we preserve the set of relids that it purports to scan and
- * attribute that to our replacement Result instead, and likewise for the
- * result_type.)
+ * See if we can reduce down stacked Result nodes to a single node. This
+ * is only possible when the nested Result has no subplan and no gating
+ * qual. If we do remove the nested Result, we maintain the relids and
+ * result_type for EXPLAIN.
*/
if (IsA(plan, Result))
{
Result *rplan = (Result *) plan;
- gplan->plan.lefttree = NULL;
- gplan->relids = rplan->relids;
- gplan->result_type = rplan->result_type;
+ if (rplan->plan.lefttree == NULL &&
+ rplan->resconstantqual == NULL)
+ {
+ gplan->plan.lefttree = NULL;
+ gplan->relids = rplan->relids;
+ gplan->result_type = rplan->result_type;
+ }
}
/*
diff --git a/src/test/regress/expected/join.out b/src/test/regress/expected/join.out
index 19e2cca548b..a7ce08f7263 100644
--- a/src/test/regress/expected/join.out
+++ b/src/test/regress/expected/join.out
@@ -6707,6 +6707,16 @@ select p.* from
One-Time Filter: false
(3 rows)
+select * from (
+ select c0 from
+ (select null::int as c0 from ((select 1) union all (select 2))) t1
+ full join (select 1) t2 on true
+ where c0 is not null
+) t3 where now() is not null;
+ c0
+----
+(0 rows)
+
-- bug 5255: this is not optimizable by join removal
begin;
CREATE TEMP TABLE a (id int PRIMARY KEY);
diff --git a/src/test/regress/sql/join.sql b/src/test/regress/sql/join.sql
index 85aed7bf704..836d4b3db07 100644
--- a/src/test/regress/sql/join.sql
+++ b/src/test/regress/sql/join.sql
@@ -2487,6 +2487,13 @@ select p.* from
(parent p left join child c on (p.k = c.k)) join parent x on p.k = x.k
where p.k = 1 and p.k = 2;
+select * from (
+ select c0 from
+ (select null::int as c0 from ((select 1) union all (select 2))) t1
+ full join (select 1) t2 on true
+ where c0 is not null
+) t3 where now() is not null;
+
-- bug 5255: this is not optimizable by join removal
begin;
--
2.43.0
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: BUG #19579: Wrong results regression
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-28 00:38 ` Re: BUG #19579: Wrong results regression David Rowley <dgrowleyml@gmail.com>
2026-07-28 05:48 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
@ 2026-07-30 18:07 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-30 23:28 ` Re: BUG #19579: Wrong results regression Michael Paquier <michael@paquier.xyz>
1 sibling, 1 reply; 7+ messages in thread
From: Ayush Tiwari @ 2026-07-30 18:07 UTC (permalink / raw)
To: David Rowley <dgrowleyml@gmail.com>; Robert Haas <robertmhaas@gmail.com>; +Cc: leis@in.tum.de; pgsql-bugs@lists.postgresql.org
Hi,
On Tue, 28 Jul 2026 at 11:18, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:
> Hi,
>
> On Tue, 28 Jul 2026 at 06:08, David Rowley <dgrowleyml@gmail.com> wrote:
>
>> On Tue, 28 Jul 2026 at 00:38, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
>> wrote:
>> > 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.
>>
>> I was looking at this last night and came to the same conclusion about
>> the mistake in create_gating_plan().
>>
>
> Thanks for the review!
>
>
>> The test case can be simplified to:
>>
>> select * from (
>> select c0 from (select null::int as c0 from ((select 1) union all
>> (select 2))) t1
>> full join (select 1) t2 on true
>> where c0 is not null
>> ) t3 where now() is not null;
>>
>> I'm not sure it's worth verifying the EXPLAIN output in the test as
>> the important part here is the result. It might not be inconceivable
>> that someone might want to chain the resconstantqual in the future
>> with:
>>
>> gplan->resconstantqual = (Node *) list_concat((List *)
>> gplan->resconstantqual, (List *) rplan->resconstantqual);
>>
>> and reduce to a single Result node.
>>
>
> Sounds good, I changed it to just the select statement.
>
>
>> I've included Robert here as I'm not all that certain why this change
>> was made. I suspect it was a misunderstanding of the comment "We might
>> have had a trivial Result plan already", where "trivial" is not well
>> defined. If that's the case, then I think the comments need work. Two
>> paragraphs seem a little excessive. Wouldn't the following suffice?
>>
>> /*
>> * See if we can reduce down stacked Result nodes to a single node. This
>> * is only possible when the nested Result has no subplan and no gating
>> * qual. If we do remove the nested Result, we maintain the relids and
>> * result_type for EXPLAIN.
>> */
>>
>
> Modified the comment as suggested above.
>
> v2 patch attached.
>
I've opened a commitfest item for this:
https://commitfest.postgresql.org/patch/7078/
Should it be in the Pg 19 open list too?
Regards,
Ayush
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: BUG #19579: Wrong results regression
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-28 00:38 ` Re: BUG #19579: Wrong results regression David Rowley <dgrowleyml@gmail.com>
2026-07-28 05:48 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-30 18:07 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
@ 2026-07-30 23:28 ` Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 7+ messages in thread
From: Michael Paquier @ 2026-07-30 23:28 UTC (permalink / raw)
To: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; +Cc: David Rowley <dgrowleyml@gmail.com>; Robert Haas <robertmhaas@gmail.com>; leis@in.tum.de; pgsql-bugs@lists.postgresql.org
On Thu, Jul 30, 2026 at 11:37:38PM +0530, Ayush Tiwari wrote:
> I've opened a commitfest item for this:
> https://commitfest.postgresql.org/patch/7078/
>
> Should it be in the Pg 19 open list too?
Yes, the claim is about f2bae51dfd5, affecting v19 and newer
versions. Please add one to make sure that we track the problem.
This way, we avoid that the problem falls into the void and gets
forgotten. Open items should have the culprit commit and be assigned
to the committer who did the commit.
There is a lot of traffic on pgsql-bugs and pgsql-hackers combined,
things tend to be forgotten if not tracked.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../amveJWkE3Dzbf_Mw@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: BUG #19579: Wrong results regression
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-28 00:38 ` Re: BUG #19579: Wrong results regression David Rowley <dgrowleyml@gmail.com>
2026-07-28 05:48 ` Re: BUG #19579: Wrong results regression Ayush Tiwari <ayushtiwari.slg01@gmail.com>
@ 2026-07-31 01:20 ` David Rowley <dgrowleyml@gmail.com>
1 sibling, 0 replies; 7+ messages in thread
From: David Rowley @ 2026-07-31 01:20 UTC (permalink / raw)
To: Ayush Tiwari <ayushtiwari.slg01@gmail.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; leis@in.tum.de; pgsql-bugs@lists.postgresql.org
On Tue, 28 Jul 2026 at 17:48, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
>
> On Tue, 28 Jul 2026 at 06:08, David Rowley <dgrowleyml@gmail.com> wrote:
>> /*
>> * See if we can reduce down stacked Result nodes to a single node. This
>> * is only possible when the nested Result has no subplan and no gating
>> * qual. If we do remove the nested Result, we maintain the relids and
>> * result_type for EXPLAIN.
>> */
>
>
> Modified the comment as suggested above.
>
> v2 patch attached.
Thank you. Pushed.
David
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-07-31 01:20 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-25 07:19 BUG #19579: Wrong results regression PG Bug reporting form <noreply@postgresql.org>
2026-07-27 12:38 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-28 00:38 ` David Rowley <dgrowleyml@gmail.com>
2026-07-28 05:48 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-30 18:07 ` Ayush Tiwari <ayushtiwari.slg01@gmail.com>
2026-07-30 23:28 ` Michael Paquier <michael@paquier.xyz>
2026-07-31 01:20 ` David Rowley <dgrowleyml@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox