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-0006bn-On@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
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/555494d1bc119173bbf712940da823303644d4de
Modified Files
--------------
src/backend/optimizer/plan/createplan.c | 10 +++++
src/backend/optimizer/plan/planner.c | 16 +-------
src/test/regress/expected/subselect.out | 69 ++++++++++++++++++++++-----------
src/test/regress/sql/subselect.sql | 25 +++++++-----
4 files changed, 72 insertions(+), 48 deletions(-)
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 |