From 5e34fe3580559c3eee82a32308d8a387c57e8dfd Mon Sep 17 00:00:00 2001 From: Amit Langote Date: Thu, 10 Sep 2026 17:17:16 +0900 Subject: [PATCH] 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 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 b95268d8c46..ea94b84ffc9 100644 --- a/src/backend/utils/adt/ri_triggers.c +++ b/src/backend/utils/adt/ri_triggers.c @@ -3444,8 +3444,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; @@ -3453,10 +3453,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;