Re: BUG #18170: Unexpected error: no relation entry for relid 3
От | Alexander Korotkov |
---|---|
Тема | Re: BUG #18170: Unexpected error: no relation entry for relid 3 |
Дата | |
Msg-id | CAPpHfdvSpfr_Fo-xABPF72xTKDzYDtBh0tfMQCvBOUEV=pDB-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18170: Unexpected error: no relation entry for relid 3 (Richard Guo <guofenglinux@gmail.com>) |
Список | pgsql-bugs |
On Mon, Oct 30, 2023 at 4:24 AM Richard Guo <guofenglinux@gmail.com> wrote: > > On Sun, Oct 29, 2023 at 11:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Alexander Korotkov <aekorotkov@gmail.com> writes: >> > I made some beautification of the patch by Andrei. I also removed the >> > part which changes the target list for estimate_num_groups(). Any >> > objections to pushing this? >> >> It seems moderately likely that this will break as much as it fixes. >> >> I've not studied the original patch enough to understand why you need >> to be playing strange games with tree mutation rules, but I suspect >> that this is band-aiding over some rather fundamentally bad code. > > > I also have some concerns about this patch. It requires that > root->parse remains unchanged during the whole subquery_planner() in > order to work, which is an implicit constraint we did not have before. I wouldn't say this is exactly what is required. Actually, the patch requires root->parse and corresponding parent_root->simple_rte_array[]->subquery to be the same. So, it's still possible to change both of them, but just don't make them distinct copies. ------ Regards, Alexander Korotkov
В списке pgsql-bugs по дате отправления: