Hi,
On January 29, 2019 4:19:52 AM PST, Petr Jelinek <petr.jelinek@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
HeapTupleUpdatedmake 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.