postgres.git / summary / log / commit / refs
commit ca3fd678f47becc5b84e0b027b2f062c5ad05b2b
Author: Amit Langote <amitlan@postgresql.org>
Date: Thu Sep 10 08:17:29 2026 +0000
Clarify RI tuple-lock result handling comments
Explain that returning false for TM_SelfModified follows ExecLockRows(),
which skips such tuples. This differs from TM_Updated, which is
unexpected in READ COMMITTED with FIND_LAST_VERSION.
Also remove "fall through to error" from the TM_Updated comment, since
the code calls elog(ERROR) directly.
Reported-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://postgr.es/m/CAA4eK1Lk1DfgiFPL-HccZm-Nm+exg+FcsODH8KPw6BOBuzfHtA@mail.gmail.com
Backpatch-through: 19
src/backend/utils/adt/ri_triggers.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.c
index ab2b5e24974..6958f991604 100644
--- a/src/backend/utils/adt/ri_triggers.c
+++ b/src/backend/utils/adt/ri_triggers.c
@@ -2928,8 +2928,8 @@ ri_LockPKTuple(Relation pk_rel, TupleTableSlot *slot, Snapshot snap,
/*
* In READ COMMITTED, FIND_LAST_VERSION should have chased the
- * chain and returned TM_Ok. Getting here means something
- * unexpected -- fall through to error.
+ * chain rather than returning TM_Updated. As in ExecLockRows(),
+ * treat this as an unexpected result.
*/
elog(ERROR, "unexpected table_tuple_lock status: %u", result);
break;
@@ -2937,10 +2937,8 @@ ri_LockPKTuple(Relation pk_rel, TupleTableSlot *slot, Snapshot snap,
case TM_SelfModified:
/*
- * The current command or a later command in this transaction
- * modified the PK row. This shouldn't normally happen during an
- * FK check (we're not modifying pk_rel), but handle it safely by
- * treating the tuple as not found.
+ * As in ExecLockRows(), ignore a tuple updated or deleted by the
+ * current command or a later command in this transaction.
*/
return false;
[parent: 25649d6e791c]