Re: regression, deadlock in high frequency single-row UPDATE - Mailing list pgsql-bugs

From Mark Kirkwood
Subject Re: regression, deadlock in high frequency single-row UPDATE
Date
Msg-id 548AA8F4.3020905@catalyst.net.nz
Whole thread Raw
In response to Re: regression, deadlock in high frequency single-row UPDATE  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: regression, deadlock in high frequency single-row UPDATE
List pgsql-bugs
On 12/12/14 06:22, Alvaro Herrera wrote:

> 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 - I was having a look at the isolationtester spec. Playing with the
pgbench setup to see the minimal number of session I needed to provoke
the deadlock  (unpatched 9.5 code) seemed to converge to about 4. I
managed to still see 1 deadlock with each session only doing 1
transaction - i.e:

$ pgbench -c 4 -C  -n -t 1 -f query.sql deadlock

...which resulted in 1 deadlock. So we may be able to get a reasonable
test case that shows this up! I'll take a look at setting up a test case
later - but don't let that stop you doing it 1st :-)

Cheers

Mark

pgsql-bugs by date:

Previous
From: Matt Freeman
Date:
Subject: Re: BUG #12202: json operator ->>with offset
Next
From: morten.hustveit@gmail.com
Date:
Subject: BUG #12209: Temporary functions may cause pg_dump to fail