Re: Why does execReplication.c lock tuples? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Why does execReplication.c lock tuples?
Date
Msg-id 44329A59-7CC8-42E6-AFC5-AFFDE938EDF4@anarazel.de
Whole thread Raw
In response to Re: Why does execReplication.c lock tuples?  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: Why does execReplication.c lock tuples?  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: COPY FROM WHEN condition
Next
From: Tom Lane
Date:
Subject: Re: Rename nodes/relation.h => nodes/pathnodes.h ?