pgsql: Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks. An updating query that reads a CTE within an InitPlan or SubPlan could get incorrect results if it updates rows that are concurrently being modified. This is caused by CteScanNext supposing that nothing inside its recursive ExecProcNode call could change which read pointer is selected in the CTE's shared tuplestore. While that's normally true because of scoping considerations, it can break down if an EPQ plan tree gets built during the call, because EvalPlanQualStart builds execution trees for all subplans whether they're going to be used during the recheck or not. And it seems like a pretty shaky assumption anyway, so let's just reselect our own read pointer here. Per bug #14870 from Andrei Gorita. This has been broken since CTEs were implemented, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171024155358.1471.82...@wrigleys.postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/159efe4af4509741c25d6b95ddd9fda86facce42 Modified Files -- src/backend/executor/nodeCtescan.c | 13 + src/test/isolation/expected/eval-plan-qual.out | 15 +++ src/test/isolation/specs/eval-plan-qual.spec | 9 + 3 files changed, 37 insertions(+)
pgsql: Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks. An updating query that reads a CTE within an InitPlan or SubPlan could get incorrect results if it updates rows that are concurrently being modified. This is caused by CteScanNext supposing that nothing inside its recursive ExecProcNode call could change which read pointer is selected in the CTE's shared tuplestore. While that's normally true because of scoping considerations, it can break down if an EPQ plan tree gets built during the call, because EvalPlanQualStart builds execution trees for all subplans whether they're going to be used during the recheck or not. And it seems like a pretty shaky assumption anyway, so let's just reselect our own read pointer here. Per bug #14870 from Andrei Gorita. This has been broken since CTEs were implemented, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171024155358.1471.82...@wrigleys.postgresql.org Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/795f2112ea284c6b4e33305e4110d1652cded200 Modified Files -- src/backend/executor/nodeCtescan.c | 13 + src/test/isolation/expected/eval-plan-qual.out | 15 +++ src/test/isolation/specs/eval-plan-qual.spec | 9 + 3 files changed, 37 insertions(+)
pgsql: Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks. An updating query that reads a CTE within an InitPlan or SubPlan could get incorrect results if it updates rows that are concurrently being modified. This is caused by CteScanNext supposing that nothing inside its recursive ExecProcNode call could change which read pointer is selected in the CTE's shared tuplestore. While that's normally true because of scoping considerations, it can break down if an EPQ plan tree gets built during the call, because EvalPlanQualStart builds execution trees for all subplans whether they're going to be used during the recheck or not. And it seems like a pretty shaky assumption anyway, so let's just reselect our own read pointer here. Per bug #14870 from Andrei Gorita. This has been broken since CTEs were implemented, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171024155358.1471.82...@wrigleys.postgresql.org Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ea6d67cf8e01a1361f7374af9fa70871cc41dc43 Modified Files -- src/backend/executor/nodeCtescan.c | 13 + src/test/isolation/expected/eval-plan-qual.out | 15 +++ src/test/isolation/specs/eval-plan-qual.spec | 9 + 3 files changed, 37 insertions(+)
pgsql: Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks. An updating query that reads a CTE within an InitPlan or SubPlan could get incorrect results if it updates rows that are concurrently being modified. This is caused by CteScanNext supposing that nothing inside its recursive ExecProcNode call could change which read pointer is selected in the CTE's shared tuplestore. While that's normally true because of scoping considerations, it can break down if an EPQ plan tree gets built during the call, because EvalPlanQualStart builds execution trees for all subplans whether they're going to be used during the recheck or not. And it seems like a pretty shaky assumption anyway, so let's just reselect our own read pointer here. Per bug #14870 from Andrei Gorita. This has been broken since CTEs were implemented, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171024155358.1471.82...@wrigleys.postgresql.org Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/517e0fe866c607795bc6990005745ba483326495 Modified Files -- src/backend/executor/nodeCtescan.c | 13 + src/test/isolation/expected/eval-plan-qual.out | 15 +++ src/test/isolation/specs/eval-plan-qual.spec | 9 + 3 files changed, 37 insertions(+)
pgsql: Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks. An updating query that reads a CTE within an InitPlan or SubPlan could get incorrect results if it updates rows that are concurrently being modified. This is caused by CteScanNext supposing that nothing inside its recursive ExecProcNode call could change which read pointer is selected in the CTE's shared tuplestore. While that's normally true because of scoping considerations, it can break down if an EPQ plan tree gets built during the call, because EvalPlanQualStart builds execution trees for all subplans whether they're going to be used during the recheck or not. And it seems like a pretty shaky assumption anyway, so let's just reselect our own read pointer here. Per bug #14870 from Andrei Gorita. This has been broken since CTEs were implemented, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171024155358.1471.82...@wrigleys.postgresql.org Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e11b6488e5a70f870bc7069d7f08a9570ccd3fc2 Modified Files -- src/backend/executor/nodeCtescan.c | 13 + src/test/isolation/expected/eval-plan-qual.out | 15 +++ src/test/isolation/specs/eval-plan-qual.spec | 9 + 3 files changed, 37 insertions(+)
pgsql: Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks. An updating query that reads a CTE within an InitPlan or SubPlan could get incorrect results if it updates rows that are concurrently being modified. This is caused by CteScanNext supposing that nothing inside its recursive ExecProcNode call could change which read pointer is selected in the CTE's shared tuplestore. While that's normally true because of scoping considerations, it can break down if an EPQ plan tree gets built during the call, because EvalPlanQualStart builds execution trees for all subplans whether they're going to be used during the recheck or not. And it seems like a pretty shaky assumption anyway, so let's just reselect our own read pointer here. Per bug #14870 from Andrei Gorita. This has been broken since CTEs were implemented, so back-patch to all supported branches. Discussion: https://postgr.es/m/20171024155358.1471.82...@wrigleys.postgresql.org Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/340d63bfb369c4f7ccbd0b224a3b36b2678ba13e Modified Files -- src/backend/executor/nodeCtescan.c | 13 + src/test/isolation/expected/eval-plan-qual.out | 15 +++ src/test/isolation/specs/eval-plan-qual.spec | 9 + 3 files changed, 37 insertions(+)
