Re: BUG #18170: Unexpected error: no relation entry for relid 3 - Mailing list pgsql-bugs

From Andrei Lepikhov
Subject Re: BUG #18170: Unexpected error: no relation entry for relid 3
Date
Msg-id 011bcae5-7840-42c7-a50c-b406189e2e78@postgrespro.ru
Whole thread Raw
In response to Re: BUG #18170: Unexpected error: no relation entry for relid 3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18170: Unexpected error: no relation entry for relid 3
List pgsql-bugs
On 27/10/2023 00:12, Tom Lane wrote:
> Vik Fearing <vik@postgresfriends.org> writes:
>> On 10/26/23 16:01, PG Bug reporting form wrote:
>>> My fuzzer finds a bug in Postgres, which triggers an unexpected error.
> 
>> This bisects to d3d55ce571369dad6e1d582f1655e5a3fbd8594a, Remove useless
>> self-joins.
> 
> I wonder if that new code thinks it can remove ref_2 from the query,
> even though ref_2 is used in the targetlist.  I'm not seeing
> control reach remove_leftjoinrel_from_query, though.

As I see, this join can be removed: in the explain you can see that 
OUTER JOIN is replaced with the INNER JOIN(ref_2, ref_3) ON a key column.
In my opinion, the origin of the problem is that the parent_root 
contains a link to ref_2 in its 
simple_rte_array[]->subquery->targetList. I am still looking for a 
general solution right now, but it doesn't look too complicated at first 
sight.

> Also, while nosing around in this, I tried to pprint(root) at the
> point of the error, and got

Yeah, it is my blunder. Alexander already fixed that, as I see. The only 
question is whether it is worth making the UniqueRelInfo structure as a 
node (for debug purposes - I see only one reason) or we should exclude 
this field from read/write operations at all.

-- 
regards,
Andrei Lepikhov
Postgres Professional




pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: missing requirement on ccache in postgresql16-devel
Next
From: Alexander Korotkov
Date:
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3