Re: v16 regression - wrong query results with LEFT JOINs + join removal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: v16 regression - wrong query results with LEFT JOINs + join removal
Date
Msg-id 1085792.1683823563@sss.pgh.pa.us
Whole thread Raw
In response to Re: v16 regression - wrong query results with LEFT JOINs + join removal  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: v16 regression - wrong query results with LEFT JOINs + join removal
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 11, 2023 at 10:14 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> Ouch, so we've had a known queries-returning-wrong-answers bug for
>> more than two months. That's not great. I'll try to find time today to
>> check whether the patches on that thread resolve this issue.

> I tried out the v3 patches from that thread and they don't seem to
> make any difference for me in this test case. So either (1) it's a
> different issue or (2) those patches don't fully fix it or (3) I'm bad
> at testing things.

Yeah, I've just traced the problem to remove_rel_from_query() deciding
that it can drop the qual of interest :-(.  I'd done this:

-       if (RINFO_IS_PUSHED_DOWN(rinfo, joinrelids))
+       if (bms_is_member(ojrelid, rinfo->required_relids))

as part of an unfinished effort at getting rid of RestrictInfos'
is_pushed_down flags, and this example shows that the replacement
condition is faulty.

What I'm inclined to do about it is just revert this particular
change.  But I'd better run around and see where else I did that,
because the idea is evidently not ready for prime time.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: base backup vs. concurrent truncation
Next
From: Tom Lane
Date:
Subject: Re: v16 regression - wrong query results with LEFT JOINs + join removal