summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2025-09-17 12:19:15 +1200
committerDavid Rowley <drowley@postgresql.org>2025-09-17 12:19:15 +1200
commitac06ea8f7b6c6aeedef9bff5fb30f606f6054a55 (patch)
treef60f7d880870e4fa8c1a1fd350c921fccdbe9c47 /src
parentdee21ea6d6178f1acd5044fd94e3dc4542e2656b (diff)
Add missing EPQ recheck for TID Range Scan
The EvalPlanQual recheck for TID Range Scan wasn't rechecking the TID qual still passed after following update chains. This could result in tuples being updated or deleted by plans using TID Range Scans where the ctid of the new (updated) tuple no longer matches the clause of the scan. This isn't desired behavior, and isn't consistent with what would happen if the chosen plan had used an Index or Seq Scan, and that could lead to hard to predict behavior for scans that contain TID quals and other quals as the planner has freedom to choose TID Range or some other non-TID scan method for such queries, and the chosen plan could change at any moment. Here we fix this by properly implementing the recheck function for TID Range Scans. Backpatch to 14, where TID Range Scans were added Reported-by: Sophie Alpert <pg@sophiebits.com> Author: Sophie Alpert <pg@sophiebits.com> Author: David Rowley <dgrowleyml@gmail.com> Reviewed-by: David Rowley <dgrowleyml@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/4a6268ff-3340-453a-9bf5-c98d51a6f729@app.fastmail.com Backpatch-through: 14
Diffstat (limited to 'src')
-rw-r--r--src/backend/executor/nodeTidrangescan.c10
-rw-r--r--src/test/isolation/expected/eval-plan-qual.out23
-rw-r--r--src/test/isolation/specs/eval-plan-qual.spec5
3 files changed, 37 insertions, 1 deletions
diff --git a/src/backend/executor/nodeTidrangescan.c b/src/backend/executor/nodeTidrangescan.c
index 26f7420b64b..1bce8d6cbfe 100644
--- a/src/backend/executor/nodeTidrangescan.c
+++ b/src/backend/executor/nodeTidrangescan.c
@@ -274,6 +274,16 @@ TidRangeNext(TidRangeScanState *node)
static bool
TidRangeRecheck(TidRangeScanState *node, TupleTableSlot *slot)
{
+ if (!TidRangeEval(node))
+ return false;
+
+ Assert(ItemPointerIsValid(&slot->tts_tid));
+
+ /* Recheck the ctid is still within range */
+ if (ItemPointerCompare(&slot->tts_tid, &node->trss_mintid) < 0 ||
+ ItemPointerCompare(&slot->tts_tid, &node->trss_maxtid) > 0)
+ return false;
+
return true;
}
diff --git a/src/test/isolation/expected/eval-plan-qual.out b/src/test/isolation/expected/eval-plan-qual.out
index 2cba44f2bde..3d31d0f84e5 100644
--- a/src/test/isolation/expected/eval-plan-qual.out
+++ b/src/test/isolation/expected/eval-plan-qual.out
@@ -1265,6 +1265,29 @@ savings | 600| 1200
(2 rows)
+starting permutation: tidrange1 tidrange2 c1 c2 read
+step tidrange1: UPDATE accounts SET balance = balance + 100 WHERE ctid BETWEEN '(0,1)' AND '(0,1)' RETURNING accountid, balance;
+accountid|balance
+---------+-------
+checking | 700
+(1 row)
+
+step tidrange2: UPDATE accounts SET balance = balance + 200 WHERE ctid BETWEEN '(0,1)' AND '(0,1)' RETURNING accountid, balance; <waiting ...>
+step c1: COMMIT;
+step tidrange2: <... completed>
+accountid|balance
+---------+-------
+(0 rows)
+
+step c2: COMMIT;
+step read: SELECT * FROM accounts ORDER BY accountid;
+accountid|balance|balance2
+---------+-------+--------
+checking | 700| 1400
+savings | 600| 1200
+(2 rows)
+
+
starting permutation: tid1 tid2 r1 c2 read
step tid1: UPDATE accounts SET balance = balance + 100 WHERE ctid = '(0,1)' RETURNING accountid, balance;
accountid|balance
diff --git a/src/test/isolation/specs/eval-plan-qual.spec b/src/test/isolation/specs/eval-plan-qual.spec
index b8983ea215f..c6eee685586 100644
--- a/src/test/isolation/specs/eval-plan-qual.spec
+++ b/src/test/isolation/specs/eval-plan-qual.spec
@@ -99,8 +99,9 @@ step upsert1 {
WHERE NOT EXISTS (SELECT 1 FROM upsert);
}
-# Tests for Tid Scan
+# Tests for Tid / Tid Range Scan
step tid1 { UPDATE accounts SET balance = balance + 100 WHERE ctid = '(0,1)' RETURNING accountid, balance; }
+step tidrange1 { UPDATE accounts SET balance = balance + 100 WHERE ctid BETWEEN '(0,1)' AND '(0,1)' RETURNING accountid, balance; }
# tests with table p check inheritance cases:
# readp1/writep1/readp2 tests a bug where nodeLockRows did the wrong thing
@@ -245,6 +246,7 @@ step wrtwcte { UPDATE table_a SET value = 'tableAValue2' WHERE id = 1; }
step wrjt { UPDATE jointest SET data = 42 WHERE id = 7; }
step tid2 { UPDATE accounts SET balance = balance + 200 WHERE ctid = '(0,1)' RETURNING accountid, balance; }
+step tidrange2 { UPDATE accounts SET balance = balance + 200 WHERE ctid BETWEEN '(0,1)' AND '(0,1)' RETURNING accountid, balance; }
# here, recheck succeeds; (0,3) is the id that step tid1 will assign
step tidsucceed2 { UPDATE accounts SET balance = balance + 200 WHERE ctid = '(0,1)' OR ctid = '(0,3)' RETURNING accountid, balance; }
@@ -401,6 +403,7 @@ permutation wrjt selectresultforupdate c2 c1
permutation wrtwcte multireadwcte c1 c2
permutation tid1 tid2 c1 c2 read
permutation tid1 tidsucceed2 c1 c2 read
+permutation tidrange1 tidrange2 c1 c2 read
# test that a rollback on s1 has s2 perform the update on the original row
permutation tid1 tid2 r1 c2 read