Re: Why does execReplication.c lock tuples?

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>,pgsql-hackers(at)postgresql(dot)org,Peter Eisentraut <peter_e(at)gmx(dot)net>,Petr Jelinek <petr(at)2ndquadrant(dot)com>
Subject: Re: Why does execReplication.c lock tuples?
Date: 2019-01-29 15:28:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On January 29, 2019 4:19:52 AM PST, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>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
>> 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
>> 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

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?

Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-01-29 15:31:39 Re: Rename nodes/relation.h => nodes/pathnodes.h ?
Previous Message Andres Freund 2019-01-29 15:22:16 Re: COPY FROM WHEN condition