It seems that a concurrent UPDATE can restart heap_lock_tuple() even if it's not necessary. Is the attached proposal correct and worth applying?
-- Antonin Houska Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index 6ac07f2fda..c3310ab4f9 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -4553,7 +4553,7 @@ l3: */ if (!HeapTupleHeaderIsOnlyLocked(tuple->t_data) && ((tuple->t_data->t_infomask2 & HEAP_KEYS_UPDATED) || - !updated)) + (!updated && follow_updates))) goto l3; /* Things look okay, so we can skip sleeping */
