Hi, On January 29, 2019 4:19:52 AM PST, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote: >Hi, > >On 20/01/2019 21:03, Andres Freund wrote: >> Hi, >> >> Currently RelationFindReplTupleByIndex(), RelationFindReplTupleSeq() >> lock the found tuple. I don't quite get what that achieves - why >isn't >> dealing with concurrency in the table_update/delete calls at the >> callsites sufficient? As far as I can tell there's no meaningful >> concurrency handling in the heap_lock_tuple() paths, so it's not like >we >> follow update chains or anything. >> > >Yeah that's leftover from the conflict detection/handling code that I >stripped away to keep the patched manageable size-wise. As things stand >now we could remove that and use normal heap_update instead of simple >variant. It'll be likely be needed again if we add conflict handling in >the future, but perhaps we could be smarter about it then (i.e. I can >imagine that it will be per table anyway, not necessarily default >behavior).
Why does conflict handling need the unconditional lock? Wouldn't just doing that after an initial heap_update returned HeapTupleUpdated make more sense? And wouldn't it need to reckeck the row afterwards as well? Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
