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
-
Add isolationtester spec for old heapam.c bug
- c9578135f769 9.6.0 landed
-
Improve concurrency of foreign key locking
- 0ac5ad5134f2 9.3.0 cited