| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: ERROR: too late to create a new PlaceHolderInfo |
| Date: | 2026-11-05 08:29:16 |
| Message-ID: | CAMbWs48eVJhGAo=cb1sPhc9aVuqU8X85zLwM2a4ib-iKif8Z+A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Nov 5, 2026 at 11:25 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> I'd like to push this to master and v19, and leave v18 and older
> alone due to ABI concerns.
Hmm, while fuzzing v3 I found that this bug can also cause wrong
results, not just errors.
create table a (k int);
create table b (k int);
insert into a values (1);
select ss.x, count(*)
from a left join (b cross join (select 1 as c) s) j on a.k = j.k
cross join lateral (select j as x) ss
where ss.x::text is not null
group by rollup (ss.x);
x | count
------+-------
NULL | 1
NULL | 1
(2 rows)
b is empty, so a's row is null-extended, ss.x is NULL, and the answer
should be a single (NULL, 0) row. We get the above wrong results on
every branch back to v16. Because of the grouping sets, pullup wraps
ss.x in a PHV, and the j inside it is flattened separately in the
targetlist and in the WHERE clause. The WHERE clause's inner PHV then
matches nothing in the join's input, so setrefs.c computes its
expression above the left join, yielding ROW(NULL, 1) instead of NULL.
This wrong-result is fixed by the patch.
Given the wrong results, I think we need to reconsider back-patching
to v16. Is fixing this in the back branches worth the risk of an ABI
break?
- Richard
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Bertrand Drouvot | 2026-11-05 08:17:22 | Re: Redesign per-backend statistics |