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
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 |