Re: Why does execReplication.c lock tuples?

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, 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 12:19:52
Message-ID: 3392745d-706f-3311-27b7-21ced146e690@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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).

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-01-29 12:21:01 Re: pg_stat_ssl additions
Previous Message Amit Kapila 2019-01-29 12:16:38 Re: WIP: Avoid creation of the free space map for small tables