Allow locking updated tuples in tuple_update() and tuple_delete()
authorAlexander Korotkov <akorotkov@postgresql.org>
Wed, 22 Mar 2023 21:13:37 +0000 (00:13 +0300)
committerAlexander Korotkov <akorotkov@postgresql.org>
Wed, 22 Mar 2023 21:26:59 +0000 (00:26 +0300)
commit11470f544e3729c60fab890145b2e839cbc8905e
tree8ebd3c5b4aab9023e54e71e892b91a5beb9de8dc
parent764da7710bf68eebb2c0facb2f871bc3c7a705b6
Allow locking updated tuples in tuple_update() and tuple_delete()

Currently, in read committed transaction isolation mode (default), we have the
following sequence of actions when tuple_update()/tuple_delete() finds
the tuple updated by concurrent transaction.

1. Attempt to update/delete tuple with tuple_update()/tuple_delete(), which
   returns TM_Updated.
2. Lock tuple with tuple_lock().
3. Re-evaluate plan qual (recheck if we still need to update/delete and
   calculate the new tuple for update).
4. Second attempt to update/delete tuple with tuple_update()/tuple_delete().
   This attempt should be successful, since the tuple was previously locked.

This patch eliminates step 2 by taking the lock during first
tuple_update()/tuple_delete() call.  Heap table access method saves some
efforts by checking the updated tuple once instead of twice.  Future
undo-based table access methods, which will start from the latest row version,
can immediately place a lock there.

The code in nodeModifyTable.c is simplified by removing the nested switch/case.

Discussion: https://postgr.es/m/CAPpHfdua-YFw3XTprfutzGp28xXLigFtzNbuFY8yPhqeq6X5kg%40mail.gmail.com
Reviewed-by: Aleksander Alekseev, Pavel Borisov, Vignesh C, Mason Sharp
Reviewed-by: Andres Freund, Chris Travers
src/backend/access/heap/heapam_handler.c
src/backend/access/table/tableam.c
src/backend/executor/nodeModifyTable.c
src/include/access/tableam.h
src/include/executor/tuptable.h
src/tools/pgindent/typedefs.list