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

From Richard Guo
Subject Re: BUG #18170: Unexpected error: no relation entry for relid 3
Date
Msg-id CAMbWs494m3AjhHry_HFCFi_SJ+6-PaeMRbx7jK39ZHmK0MVOUA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18170: Unexpected error: no relation entry for relid 3  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
Responses 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  (Andrei Lepikhov <a.lepikhov@postgrespro.ru>)
List pgsql-bugs

On Fri, Oct 27, 2023 at 7:00 PM Andrei Lepikhov <a.lepikhov@postgrespro.ru> wrote:
So, I can propose two options. First - don't clean only the current root
structure, but also make cleanup of the parent. Although it looks safe,
I am not happy with this approach - it seems too simple: we should have
a genuine reason for such a cleaning because it potentially adds overhead.
The second option is to add a flag for not altering queries in
remove_nulling_relids() - it looks like a mistake when we have two
different query trees in the root and its parent. Also, it reduces
memory usage a bit.
So, if my analysis is correct, it is better to use the second way (see
attachment).

Alternatively, can we look at subroot->parse->targetList instead of
subquery->targetList where we call estimate_num_groups on the output of
the subquery?

--- a/src/backend/optimizer/prep/prepunion.c
+++ b/src/backend/optimizer/prep/prepunion.c
@@ -341,7 +341,7 @@ recurse_set_operations(Node *setOp, PlannerInfo *root,
        *pNumGroups = subpath->rows;
    else
        *pNumGroups = estimate_num_groups(subroot,
-                                         get_tlist_exprs(subquery->targetList, false),
+                                         get_tlist_exprs(subroot->parse->targetList, false),
                                          subpath->rows,
                                          NULL,
                                          NULL);

BTW, I'm a little surprised that QTW_DONT_COPY_QUERY doesn't seem to be
used anywhere currently.

Thanks
Richard

pgsql-bugs by date:

Previous
From: hubert depesz lubaczewski
Date:
Subject: Logical replication is missing block of rows when sending initial sync?
Next
From: Tom Lane
Date:
Subject: Re: BUG #18170: Unexpected error: no relation entry for relid 3