From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ERROR: no relation entry for relid 6 |
Date: | 2023-05-26 16:16:51 |
Message-ID: | 1998182.1685117811@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Fri, May 26, 2023 at 6:06 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Based on what deconstruct_distribute_oj_quals is doing, it seems
>> likely to me that there are cases that require ignoring
>> commute_above_r, but I've not tried to devise one. It'd be good to
>> have one to include in the commit, if we can find one.
> It seems that queries of the second form of identity 3 require ignoring
> commute_above_r.
> select 1 from t t1 left join (t t2 left join t t3 on t2.a = t3.a) on
> t1.a = t2.a;
> When removing t2/t3 join, the clone of 't2.a = t3.a' with t1 join in the
> nulling bitmap would be put back if we do not ignore commute_above_r.
> There is no observable problem though because it would be rejected later
> in subbuild_joinrel_restrictlist, but still I think it should not be put
> back in the first place.
Ah. I realized that we could make the problem testable by adding
assertions that a joinclause we're not removing doesn't contain
any surviving references to the target rel or join. That turns
out to fire (without the bug fix) in half a dozen existing test
cases, so I felt that we didn't need to add another one.
I did the other refactoring we discussed and pushed it.
Thanks for the report and review!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kaiting Chen | 2023-05-26 16:23:40 | Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot? |
Previous Message | Jacob Champion | 2023-05-26 16:10:17 | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |