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
-
Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify.
- 7fc7dac1a711 11.0 landed
-
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
- 1bc0100d270e 11.0 cited