From a4b68bdfd5190a8727a0b8615c292c26b76c99da Mon Sep 17 00:00:00 2001 From: Amit Langote Date: Wed, 9 Sep 2026 20:45:54 +0900 Subject: [PATCH v6 1/2] 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 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; -- 2.47.3