1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Fix placement of initPlans when forcibly materializing a subplan.

If we forcibly place a Material node atop a finished subplan, we need
to move any initPlans attached to the subplan up to the Material node,
in order to keep SS_finalize_plan() happy.  I'd figured this out in
commit 7b67a0a49 for the case of materializing a cursor plan, but out of
an abundance of caution, I put the initPlan movement hack at the call
site for that case, rather than inside materialize_finished_plan().
That was the wrong thing, because it turns out to also be necessary for
the only other caller of materialize_finished_plan(), ie subselect.c.
We lacked any test cases that exposed the mistake, but bug#14524 from
Wei Congrui shows that it's possible to get an initPlan reference into
the top tlist in that case too, and then SS_finalize_plan() complains.
Hence, move the hack into materialize_finished_plan().

In HEAD, also relocate some recently-added tests in subselect.sql, which
I'd unthinkingly dropped into the middle of a sequence of related tests.

Report: https://postgr.es/m/20170202060020.1400.89021@wrigleys.postgresql.org
This commit is contained in:
Tom Lane
2017-02-02 19:11:27 -05:00
parent aa09b9dcd5
commit 555494d1bc
4 changed files with 72 additions and 48 deletions

View File

@ -316,21 +316,7 @@ standard_planner(Query *parse, int cursorOptions, ParamListInfo boundParams)
if (cursorOptions & CURSOR_OPT_SCROLL)
{
if (!ExecSupportsBackwardScan(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;
}
top_plan = materialize_finished_plan(top_plan);
}
/*