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

From Alexander Korotkov
Subject Re: BUG #18170: Unexpected error: no relation entry for relid 3
Date
Msg-id CAPpHfdsnAbg8CaK+NJ8AkiG_+_Tt07eCStkb1LOa50f0UsT5RQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18170: Unexpected error: no relation entry for relid 3  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: BUG #18170: Unexpected error: no relation entry for relid 3  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
List pgsql-bugs
On Wed, Nov 1, 2023 at 12:29 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> On Sat, Oct 28, 2023 at 12:12 AM Alexander Korotkov
> <aekorotkov@gmail.com> wrote:
> >
> > On Fri, Oct 27, 2023 at 5:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > Richard Guo <guofenglinux@gmail.com> writes:
> > > > Alternatively, can we look at subroot->parse->targetList instead of
> > > > subquery->targetList where we call estimate_num_groups on the output of
> > > > the subquery?
> > >
> > > Please read the comment just above that.
> >
> > Thank you, Tom,  This is clear.
>
>
> Hmm...  I just found that I wasn't attentive enough.  The proposed
> change is to use subroot->parse->targetList, not
> subroot->processed_tlist.  I don't know what could be the problem
> here.

My proposal is to use the attached patch as a hotfix for the bug considered.

And for future I propose to consider two questions (each should
probably go to its own thread):
1) Getting rid of having two distinct copies of parse tree (have one
copy instead).
2) Introduce relation aliases to simplify self-join removal.

Any thoughts?

------
Regards,
Alexander Korotkov

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17552: pg_stat_statements tracks internal FK check queries when COPY used to load data
Next
From: PG Bug reporting form
Date:
Subject: BUG #18177: certain queries under certain contexts take multiple orders of magnitude longer compared to v10