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

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Andrew Sackville-West <awest@janrain.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, hubert depesz lubaczewski <depesz@gmail.com>, Mark Kirkwood <mark.kirkwood@catalyst.net.nz>, pgsql-bugs@postgresql.org, Paulo Tanimoto <paulo@janrain.com>
Date: 2014-12-09T17:43:20Z
Lists: pgsql-bugs
On 2014-12-09 09:38:33 -0800, Andrew Sackville-West wrote:
> On Tue, Dec 9, 2014 at 6:14 AM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
> 
> > hubert depesz lubaczewski wrote:
> > > For whatever it's worth, I was able to bisect the problem to this commit:
> > >
> > > commit
> > > 0ac5ad5134f2769ccbaefec73844f8504c4d6182
> > >
> > > Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> > >
> > > Date:   Wed Jan 23 12:04:59 2013 -0300
> > >
> > >     Improve concurrency of foreign key locking
> >
> > I'm not surprised in the least, TBH.
> >
> >
> Thanks for your attention to this. Is there anything we're doing wrong that
> could improve this in current 9.3 versions?

I don't think anybody can seriously can give you a serious workaround
until the issue has been diagnosed further.

One thing you could try would be to create a unique index that spans all
the columns in the table... That'd prevent usage of lower locklevels
added in the above commit.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Commits

  1. Add isolationtester spec for old heapam.c bug

  2. Improve concurrency of foreign key locking