To: Josh Berkus <josh@agliodbs.com>
cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Anyone seen this kind of lock pileup? 
In-reply-to: <4CE46856.7070006@agliodbs.com> 
References: <4CE412F4.4090101@agliodbs.com> <24934.1290031132@sss.pgh.pa.us>
	<4CE46856.7070006@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Wed, 17 Nov 2010 15:42:14 -0800"
Date: Wed, 17 Nov 2010 18:56:44 -0500
Message-ID: <27473.1290038204@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Josh Berkus <josh@agliodbs.com> writes:
> Ok, I've collected more data.   Looks like the case I was examining was
> idiosyncratic; most of these lock pile-ups involve 400 or more locks
> waiting held by around 20 different backends.  Given this, taking 3
> seconds to sort that all out doesn't seem that unreasonable.
> Presumably there's a poll cycle of some sort for waiting statements?

No ... but if the lock requests were mutually exclusive, I could believe
it taking 3 seconds for all of the waiting backends to get their turn
with the lock, do whatever they were gonna do, commit, and release the
lock to the next guy.

> Anyway, the obvious answer is for the user to fix their application.

Probably.

			regards, tom lane