Re: ERROR: no relation entry for relid 6

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: ERROR: no relation entry for relid 6
Date: 2023-05-23 11:45:15
Message-ID: CAMbWs4_8LeiM3Z-UnHRrcksxkj6aPj6EnYMd7_g+ARO98Q8Jnw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 23, 2023 at 2:38 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:

> I came across $subject on master and here is the query I'm running.
>
> create table t (a int unique, b int);
>
> explain (costs off)
> select 1 from t t1
> left join t t2 on true
> inner join t t3 on true
> left join t t4 on t2.a = t4.a and t2.a = t3.a;
> ERROR: no relation entry for relid 6
>
> I looked into it and it should be caused by some problem in outer-join
> removal. After we've decided that the join to t4 is removable, which is
> no problem, one of the things we need to do is to remove any joinquals
> referencing t4 from the joininfo lists. In this query, there are two
> such quals, 't2.a = t4.a' and 't2.a = t3.a'. And both quals have two
> versions, one with t1/t2 join in their nulling bitmap and one without.
> The former version would be treated as being "pushed down" because its
> required_relids exceed the scope of joinrelids, due to the t1/t2 join
> included in the qual's nulling bitmap but not included in joinrelids.
> And as a result this version of quals would be put back. I think this
> is where the problem is. Ideally we should not put them back.
>
> This issue seems to have existed for a while, and is revealed by the
> change in c8b881d2 recently. I'm not sure how to fix it yet. What I'm
> thinking is that maybe this has something to do with the loose ends we
> have in make_outerjoininfo. Actually in this query the t1/t2 join
> cannot commute with the join to t4. If we can know that in
> make_outerjoininfo, we'd have added t1/t2 join to the min_lefthand of
> the join to t4, and that would avoid this issue.
>

Considering that clone clauses should always be outer-join clauses not
filter clauses, I'm wondering if we can add an additional check for that
in RINFO_IS_PUSHED_DOWN, something like

#define RINFO_IS_PUSHED_DOWN(rinfo, joinrelids) \
- ((rinfo)->is_pushed_down || \
- !bms_is_subset((rinfo)->required_relids, joinrelids))
+ (!((rinfo)->has_clone || ((rinfo)->is_clone)) && \
+ ((rinfo)->is_pushed_down || \
+ !bms_is_subset((rinfo)->required_relids, joinrelids)))

This change can fix the case shown upthread. But I doubt it's the
perfect fix we want.

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2023-05-23 11:55:48 Re: running logical replication as the subscription owner
Previous Message Daniele Varrazzo 2023-05-23 11:22:20 Re: [PoC] Federated Authn/z with OAUTHBEARER