diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-02-19 16:00:18 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-02-19 16:00:31 -0500 |
| commit | 159efe4af4509741c25d6b95ddd9fda86facce42 (patch) | |
| tree | 0b197033b531a7eac4ad45266c6bc367b8670d34 /src/backend/executor/nodeProjectSet.c | |
| parent | 4108a28d3a02c4226b0f558cf00738e00e8ea2a1 (diff) | |
| download | postgresql-159efe4af4509741c25d6b95ddd9fda86facce42.tar.gz postgresql-159efe4af4509741c25d6b95ddd9fda86facce42.zip | |
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.82377@wrigleys.postgresql.org
Diffstat (limited to 'src/backend/executor/nodeProjectSet.c')
0 files changed, 0 insertions, 0 deletions