pgsql: Fix placement of initPlans when forcibly materializing a subplan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix placement of initPlans when forcibly materializing a subplan
Date: 2017-02-03 00:11:49
Message-ID: E1cZRTh-0006bo-Oh@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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

Branch
------
REL9_6_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/b971a98cea988e03054077db613fc893564f7bf7

Modified Files
--------------
src/backend/optimizer/plan/createplan.c | 10 ++++++++++
src/backend/optimizer/plan/planner.c | 16 +---------------
src/test/regress/expected/subselect.out | 23 +++++++++++++++++++++++
src/test/regress/sql/subselect.sql | 5 +++++
4 files changed, 39 insertions(+), 15 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-02-03 00:49:23 pgsql: Avoid improbable null pointer dereference in pgpassfileWarning()
Previous Message Peter Eisentraut 2017-02-02 21:50:40 pgsql: doc: Add missing include in example code