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

(2018/05/17 14:19), Amit Langote wrote:
> Looking at this for a bit, I wondered if this crash wouldn't have occurred
> if the "propagation" had also considered join relations in addition to
> simple relations. For example, if I changed inheritance_planner like the
> attached (not proposing that we consider committing it), reported crash
> doesn't occur. The fact that it's not currently that way means that
> somebody thought that there is no point in keeping all of those joinrels
> around until plan creation time.

One reason for that would be that we use the per-child PlannerInfo, not
the parent one, at plan creation time. Here is the code in
create_modifytable_plan:

/*
* In an inherited UPDATE/DELETE, reference the per-child modified
* subroot while creating Plans from Paths for the child rel.
This is
* a kluge, but otherwise it's too hard to ensure that Plan
creation
* functions (particularly in FDWs) don't depend on the contents of
* "root" matching what they saw at Path creation time. The main
* downside is that creation functions for Plans that might appear
* below a ModifyTable cannot expect to modify the contents of
"root"
* and have it "stick" for subsequent processing such as setrefs.c.
* That's not great, but it seems better than the alternative.
*/
subplan = create_plan_recurse(subroot, subpath, CP_EXACT_TLIST);

So, we don't need to accumulate the joinrel lists for child relations
into a single list and store that list into the parent PlannerInfo in
inheritance_planner, as in the patch you proposed. I think the change
by the commit is based on the same idea as that.

Best regards,
Etsuro Fujita