From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, Ronald Cruz <cruz(at)rentec(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Ford <pford(at)rentec(dot)com>, "Aaron J(dot) Garcia" <agarcia(at)rentec(dot)com> |
Subject: | Re: Query result differences between PostgreSQL 17 vs 16 |
Date: | 2025-02-28 08:47:09 |
Message-ID: | CAMbWs4-ATTw82Pc3B+64im26JQEWHemC-6VcGzqqqo_mjCEqpw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Feb 27, 2025 at 1:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've not actually worked through the bug case to verify my hypothesis
> that it's the lack of a representative for a clone group that is
> breaking things. (Maybe you did?) But if that is the direct
> cause of the failure, then it's plausible that none of these
> callers are subject to it.
Yeah, I think this is the cause of the failure. Specifically, when we
start with (A/B)/C and transform to A/(B/C) per OJ identity 3, we need
a way to prevent upper clauses that use only C Vars from being pushed
down and applied as a filter clause at the lower B/C join. To achieve
this, we consider that the pushed-down B/C join has not completed, and
hence do not include B/C join's ojrelid in its relid set (it will be
added when we form the A/B join).
This is why, in this case, the version of 'customer.cid IS NOT NULL'
that is not marked as nullable by the left join to customer is chosen:
we've assumed that that left join has not completed yet. However,
performing the NOT NULL deduction on this clone would be unsafe. It
seems to me that, for clone clauses, the nullingrels mark is not that
reliable for performing such deductions.
> I'm a bit inclined to argue that we should put in the no-clone-quals
> limitation anyway, to protect future callers that might not manage
> to dodge the problem.
Now I'm inclined to agree with you. It seems we've been lucky so far
not to encounter issues with IS NULL deductions on clone clauses, but
this feels like a problem waiting to happen in the future.
The no-clone-quals limitation in restriction_is_always_false makes the
fix in f00ab1fd1 unnecessary. I think we should revert those changes.
Attached is the updated patch.
> OTOH, if we get rid of these functions
> altogether as I expressed my desire to do nearby, it's all moot.
Yeah, if we can find a way to perform the NullTest deduction during
eval_const_expressions, it will be much cleaner.
Thanks
Richard
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Avoid-NullTest-deduction-for-clone-clauses.patch | application/octet-stream | 17.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-02-28 15:48:18 | Re: Query result differences between PostgreSQL 17 vs 16 |
Previous Message | PG Bug reporting form | 2025-02-27 19:08:18 | BUG #18827: PostgreSQL 17.4-1 Installation – Database Cluster Initialization Failed Due to Execution Policy |