database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Clarify RI tuple-lock result handling comments

Browse Source 
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
This commit is contained in:
Amit Langote
2026-09-10 17:17:16 +09:00
parent bd9d6ffa1a
commit 5e34fe3580
1 changed files with 4 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/utils/adt/ri_triggers.c
View File

@@ -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;