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

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andrew Sackville-West <awest(at)janrain(dot)com>, pgsql-bugs(at)postgresql(dot)org, Paulo Tanimoto <paulo(at)janrain(dot)com>
Subject: Re: regression, deadlock in high frequency single-row UPDATE
Date: 2014-12-12 08:36:04
Message-ID: 548AA8F4.3020905@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2014-12-12 20:52:54 Re: regression, deadlock in high frequency single-row UPDATE
Previous Message morten.hustveit 2014-12-12 08:22:41 BUG #12209: Temporary functions may cause pg_dump to fail