Possible optimization of heap_lock_tuple()
Started by Antonin Houskaover 4 years ago1 messages
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
Attachments:
heap_lock_tuple.difftext/x-diffDownload
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 */