On 12/12/14 06:22, 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. It does solve the deadlock in my simplified
> test case. If Andrew can confirm that it fixes his original problem
> too, that'd be good.
>
> Before this can be committed I need an isolationtester spec file that
> reproduces the problem. Now that I understand why it happens it should
> be easy to produce: just have a transaction that does BEGIN, then the
> insert, and keeps the transaction open; enough other sessions run the
> UPDATE until the problem pops up. (Also, comments on
> Would_MultiXactIdWait_Block need work.)
>
> FWIW this code should also have slightly better performance than the
> original coding, since the heavyweight tuple lock acquisition is skipped
> in some cases. Not sure if that is measurable, though. Maybe in
> extreme cases such as the one in #8470 ...
>
Yeah, works for me too. I've tried your simplified and also Andrew's
original schema + queries against 9.5devel with deadlock.patch applied
(neither show any deadlocks in that case).
Cheers
Mark