Re: BUG #18170: Unexpected error: no relation entry for relid 3
От | Andrei Lepikhov |
---|---|
Тема | Re: BUG #18170: Unexpected error: no relation entry for relid 3 |
Дата | |
Msg-id | 011bcae5-7840-42c7-a50c-b406189e2e78@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: BUG #18170: Unexpected error: no relation entry for relid 3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18170: Unexpected error: no relation entry for relid 3
|
Список | 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 по дате отправления: