Re: regression, deadlock in high frequency single-row UPDATE

Mark Kirkwood <mark.kirkwood@catalyst.net.nz>

From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andrew Sackville-West <awest@janrain.com>, pgsql-bugs@postgresql.org, Paulo Tanimoto <paulo@janrain.com>
Date: 2014-12-14T02:24:47Z
Lists: pgsql-bugs
On 14/12/14 15:22, Mark Kirkwood wrote:
> On 13/12/14 10:57, Alvaro Herrera wrote:
>> Alvaro Herrera wrote:
>>> Alvaro Herrera wrote:
>>>
>>>> I'm going to experiment with that idea and see if it leads to a
>>>> solution.  I tried the other idea yesterday (to keep the HW tuple lock
>>>> we acquire in heap_lock_tuple until heap_update is done) but aside from
>>>> being very complicated and bug-prone, it doesn't solve the problem
>>>> anyway.
>>>
>>> Here's a preliminary patch.
>>
>> Here's a finished version of this patch, which I messed a bit with and
>> so needs some extra testing.  I want to push this shortly and backpatch
>> to 9.4 and 9.3.  I don't want to disrupt the 9.4.0 release next week,
>> but it'd be nice not to ship it with this bug.
>>
>
> This patch seems good too. I'm possibly seeing it performing slightly
> slower than the previous patch (approx 68 tps vs 63 on average -
> completely untuned 9.5 running on a single SATA drive, but that could
> just be natural variation/noise).
>

Blast - and forgot to clarify that "seems good" means I've tested it 
against both your and Andrew's deadlock producing schema (no deadlocks 
with this patch applied)...

Cheers

Mark



Commits

  1. Add isolationtester spec for old heapam.c bug

  2. Improve concurrency of foreign key locking