You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
Import upstream postgres commit a033f9165c2c024756d9cd3033263724d53fd9ef from REL_15_STABLE.
(master commit: 87f3667ec079c4acc2c87be51bf41e54d0b6f698)
This is needed to fix a crash/error involving UPDATE projections on partitions with out-of-order columns.
**Changes from upstream commit**
- Import regress test validating fix from `inherit.*` to `yb.port.inherit.*`.
- Remove GUC disabling INSERT ... ON CONFLICT read batching from specific queries in `yb.port.update.*`.
- Add tests involving UPDATE projections on partitions with out-of-order columns to `yb.orig.partition_out_of_order.*`.
**Upstream commit message**
```
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/[email protected]
```
Jira: DB-14307
Test Plan:
Run the following tests:
```
./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressInherit'
./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressPartitions#misc'
./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressPartitions#yb_partitions_tests'
```
Reviewers: jason
Reviewed By: jason
Subscribers: smishra, yql
Tags: #jenkins-ready
Differential Revision: https://phorge.dev.yugabyte.com/D42955
0 commit comments