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