pgsql: Fix MULTIEXPR_SUBLINK with partitioned target tables, yet again.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Fix MULTIEXPR_SUBLINK with partitioned target tables, yet again.
Дата
Msg-id E1pW0TH-000gvK-J2@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
Fix MULTIEXPR_SUBLINK with partitioned target tables, yet again.

We already tried to fix this in commits 3f7323cbb et al (and follow-on
fixes), but now it emerges that there are still unfixed cases;
moreover, these cases affect all branches not only pre-v14.  I thought
we had eliminated all cases of making multiple clones of an UPDATE's
target list when we nuked inheritance_planner.  But it turns out we
still do that in some partitioned-UPDATE cases, notably including
INSERT ... ON CONFLICT UPDATE, because ExecInitPartitionInfo thinks
it's okay to clone and modify the parent's targetlist.

This fix is based on a suggestion from Andres Freund: let's stop
abusing the ParamExecData.execPlan mechanism, which was only ever
meant to handle initplans, and instead solve the execution timing
problem by having the expression compiler move MULTIEXPR_SUBLINK steps
to the front of their expression step lists.  This is feasible because
(a) all branches still in support compile the entire targetlist of
an UPDATE into a single ExprState, and (b) we know that all
MULTIEXPR_SUBLINKs do need to be evaluated --- none could be buried
inside a CASE, for example.  There is a minor semantics change
concerning the order of execution of the MULTIEXPR's subquery versus
other parts of the parent targetlist, but that seems like something
we can get away with.  By doing that, we no longer need to worry
about whether different clones of a MULTIEXPR_SUBLINK share output
Params; their usage of that data structure won't overlap.

Per bug #17800 from Alexander Lakhin.  Back-patch to all supported
branches.  In v13 and earlier, we can revert 3f7323cbb and follow-on
fixes; however, I chose to keep the SubPlan.subLinkId field added
in ccbb54c72.  We don't need that anymore in the core code, but it's
cheap enough to fill, and removing a plan node field in a minor
release seems like it'd be asking for trouble.

Andres Freund and Tom Lane

Discussion: https://postgr.es/m/17800-ff90866b3906c964@postgresql.org

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/1e199c25994791842fe2f80c0809c2e69a3a7d2e

Modified Files
--------------
src/backend/executor/execExpr.c        | 149 ++++++++++++++++++++++---------
src/backend/executor/nodeSubplan.c     | 134 ++++++++++++++--------------
src/backend/optimizer/plan/planner.c   |   4 -
src/backend/optimizer/plan/subselect.c | 129 ---------------------------
src/include/nodes/primnodes.h          |  10 +--
src/include/optimizer/subselect.h      |   1 -
src/test/regress/expected/inherit.out  | 158 ++++++++++++++++++++-------------
src/test/regress/sql/inherit.sql       |  48 ++++++----
8 files changed, 306 insertions(+), 327 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: pgsql: Fix mishandling of OLD/NEW references in subqueries in rule acti
Следующее
От: Dean Rasheed
Дата:
Сообщение: pgsql: Doc: Miscellaneous doc updates for MERGE.