Re: BUG #18170: Unexpected error: no relation entry for relid 3

On Fri, Oct 27, 2023 at 9:31 AM Andrei Lepikhov
<a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
> On 27/10/2023 00:12, Tom Lane wrote:
> > Vik Fearing <vik(at)postgresfriends(dot)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.

Yes, I came to the same conclusion. We process root->parse. But I
didn't get why parent_root->simple_rte_array[]->subquery is not the
same as root->parse. They look the same, but they are distinct
copies. If they were the same pointers, there would be no problem.

> > 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.

I think we just shouldn't break the general rule, that everything
inside the node should be nodes too.

------
Regards,
Alexander Korotkov