Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETE joins to remote servers

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-05-16T16:16:01Z
Lists: pgsql-hackers
On Fri, May 11, 2018 at 8:46 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> I added an assertion test to make_modifytable to match that in
> create_modifytable_path.  Attached is an updated version of the patch.

Committed.  Was it just good luck that this ever worked at all?  I mean:

-        if (rti < root->simple_rel_array_size &&
-            root->simple_rel_array[rti] != NULL)
+        if (rti < subroot->simple_rel_array_size &&
+            subroot->simple_rel_array[rti] != NULL)
         {
-            RelOptInfo *resultRel = root->simple_rel_array[rti];
+            RelOptInfo *resultRel = subroot->simple_rel_array[rti];

             fdwroutine = resultRel->fdwroutine;
         }
         else
         {
-            RangeTblEntry *rte = planner_rt_fetch(rti, root);
+            RangeTblEntry *rte = planner_rt_fetch(rti, subroot);

...an RTI is only meaningful relative to a particular PlannerInfo's
range table.  It can't be right to just take an RTI for one
PlannerInfo and look it up in some other PlannerInfo's range table.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


Commits

  1. Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify.

  2. postgres_fdw: Push down UPDATE/DELETE joins to remote servers.