database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-02 09:02:37 +03:00
Code Activity

Fix some interrelated planner issues with initPlans and Param munging.

Browse Source 
In commit 68fa28f77 I tried to teach SS_finalize_plan() to cope with
initPlans attached anywhere in the plan tree, by dint of moving its
handling of those into the recursion in finalize_plan().  It turns out that
that doesn't really work: if a lower-level plan node emits an initPlan
output parameter in its targetlist, it's legitimate for upper levels to
reference those Params --- and at the point where this code runs, those
references look just like the Param itself, so finalize_plan() quite
properly rejects them as being in the wrong place.  We could lobotomize
the checks enough to allow that, probably, but then it's not clear that
we'd have any meaningful check for misplaced Params at all.  What seems
better, at least in the near term, is to tweak standard_planner() a bit
so that initPlans are never placed anywhere but the topmost plan node
for a query level, restoring the behavior that occurred pre-9.6.  Possibly
we can do better if this code is ever merged into setrefs.c: then it would
be possible to check a Param's placement only when we'd failed to replace
it with a Var referencing a child plan node's targetlist.

BTW, I'm now suspicious that finalize_plan is doing the wrong thing by
returning the node's allParam rather than extParam to be incorporated
in the parent node's set of used parameters.  However, it makes no
difference given that initPlans only appear at top level, so I'll leave
that alone for now.

Another thing that emerged from this is that standard_planner() needs
to check for initPlans before deciding that it's safe to stick a Gather
node on top in force_parallel_mode mode.  We previously guarded against
that by deciding the plan wasn't wholePlanParallelSafe if any subplans
had been found, but after commit 5ce5e4a12 it's necessary to have this
substitute test, because path parallel_safe markings don't account for
initPlans.  (Normally, we'd have decided the paths weren't safe anyway
due to appearances of SubPlan nodes, Params, or CTE scans somewhere in
the tree --- but it's possible for those all to be optimized away while
initPlans still remain.)

Per fuzz testing by Andreas Seltenreich.

Report: <874m89rw7x.fsf@credativ.de>
This commit is contained in:
Tom Lane
2016-07-01 20:05:55 -04:00
parent 48bfeb244f
commit 7b67a0a49c
5 changed files with 122 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
src/backend/optimizer/plan/planner.c
View File

@ -305,15 +305,33 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
if (cursorOptions & CURSOR_OPT_SCROLL)
{
if (!ExecSupportsBackwardScan(top_plan))
top_plan = materialize_finished_plan(top_plan);
{
Plan *sub_plan = top_plan;
top_plan = materialize_finished_plan(sub_plan);
/*
* XXX horrid kluge: if there are any initPlans attached to the
* formerly-top plan node, move them up to the Material node. This
* prevents failure in SS_finalize_plan, which see for comments.
* We don't bother adjusting the sub_plan's cost estimate for
* this.
*/
top_plan->initPlan = sub_plan->initPlan;
sub_plan->initPlan = NIL;
}
}
/*
* Optionally add a Gather node for testing purposes, provided this is
* actually a safe thing to do.
* actually a safe thing to do. (Note: we assume adding a Material node
* above did not change the parallel safety of the plan, so we can still
* rely on best_path->parallel_safe. However, that flag doesn't account
* for initPlans, which render the plan parallel-unsafe.)
*/
if (best_path->parallel_safe &&
force_parallel_mode != FORCE_PARALLEL_OFF)
if (force_parallel_mode != FORCE_PARALLEL_OFF &&
best_path->parallel_safe &&
top_plan->initPlan == NIL)
{
Gather *gather = makeNode(Gather);