Re: "variable not found in subplan target list" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "variable not found in subplan target list"
Date
Msg-id 3508847.1680014789@sss.pgh.pa.us
Whole thread Raw
In response to Re: "variable not found in subplan target list"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> The planner is reducing the scan of target_parted to
> a dummy scan, as is reasonable, but it forgets to
> provide ctid as an output from that scan; then the
> parent join node is unhappy because it does have
> a ctid output.  So it looks like the problem is some
> shortcut we take while creating the dummy scan.

Oh, actually the problem is in distribute_row_identity_vars,
which is supposed to handle this case, but it thinks it doesn't
have to back-fill the rel's reltarget.  Wrong.  Now that I see
the problem, I wonder if we can't reproduce a similar symptom
without MERGE, which would mean that v14 has the issue too.

The attached seems to fix it, but I'm going to look for a
non-MERGE test case before pushing.

            regards, tom lane

diff --git a/src/backend/optimizer/util/appendinfo.c b/src/backend/optimizer/util/appendinfo.c
index 9d377385f1..c1b1557570 100644
--- a/src/backend/optimizer/util/appendinfo.c
+++ b/src/backend/optimizer/util/appendinfo.c
@@ -21,6 +21,7 @@
 #include "nodes/nodeFuncs.h"
 #include "optimizer/appendinfo.h"
 #include "optimizer/pathnode.h"
+#include "optimizer/planmain.h"
 #include "parser/parsetree.h"
 #include "utils/lsyscache.h"
 #include "utils/rel.h"
@@ -994,9 +995,10 @@ distribute_row_identity_vars(PlannerInfo *root)
      * certainly process no rows.  Handle this edge case by re-opening the top
      * result relation and adding the row identity columns it would have used,
      * as preprocess_targetlist() would have done if it weren't marked "inh".
-     * (This is a bit ugly, but it seems better to confine the ugliness and
-     * extra cycles to this unusual corner case.)  We needn't worry about
-     * fixing the rel's reltarget, as that won't affect the finished plan.
+     * Then re-run build_base_rel_tlists() to ensure that the added columns
+     * get propagated to the relation's reltarget.  (This is a bit ugly, but
+     * it seems better to confine the ugliness and extra cycles to this
+     * unusual corner case.)
      */
     if (root->row_identity_vars == NIL)
     {
@@ -1006,6 +1008,8 @@ distribute_row_identity_vars(PlannerInfo *root)
         add_row_identity_columns(root, result_relation,
                                  target_rte, target_relation);
         table_close(target_relation, NoLock);
+        build_base_rel_tlists(root, root->processed_tlist);
+        /* There are no ROWID_VAR Vars in this case, so we're done. */
         return;
     }


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Missing update of all_hasnulls in BRIN opclasses
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Support logical replication of DDLs