X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 479AF9FA5F0 for ; Wed, 31 May 2006 12:09:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 49128-08 for ; Wed, 31 May 2006 12:09:19 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from wolff.to (wolff.to [66.93.197.194]) by postgresql.org (Postfix) with SMTP id 368089FA5DD for ; Wed, 31 May 2006 12:09:18 -0300 (ADT) Received: (qmail 22293 invoked by uid 500); 31 May 2006 15:11:41 -0000 Date: Wed, 31 May 2006 10:11:41 -0500 From: Bruno Wolff III To: "Jim C. Nasby" Cc: Greg Stark , Brendan Duddridge , Tom Lane , PostgreSQL Performance Subject: Re: App very unresponsive while performing simple update Message-ID: <20060531151141.GA20992@wolff.to> Mail-Followup-To: Bruno Wolff III , "Jim C. Nasby" , Greg Stark , Brendan Duddridge , Tom Lane , PostgreSQL Performance References: <961F6F02-4B00-494C-B071-6DF76A305C14@clickspace.com> <21B15664-F4EE-462C-88B4-EEEB2B4A979F@clickspace.com> <874pzanvk6.fsf@stark.xeocode.com> <17733.1148832292@sss.pgh.pa.us> <3C756C36-DC66-4D13-B2CE-99CFCE7BF390@clickspace.com> <87hd39n3c4.fsf@stark.xeocode.com> <20060531062307.GG53487@pervasive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060531062307.GG53487@pervasive.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/567 X-Sequence-Number: 19354 On Wed, May 31, 2006 at 01:23:07 -0500, "Jim C. Nasby" wrote: > On Sun, May 28, 2006 at 07:20:59PM -0400, Greg Stark wrote: > > Brendan Duddridge writes: > > More likely you were blocking on some lock. Until that other query holding > > that lock tries to commit Postgres won't actually detect a deadlock, it'll > > just sit waiting until the lock becomes available. > > Wow, are you sure that's how it works? I would think it would be able to > detect deadlocks as soon as both processes are waiting on each other's > locks. I don't see how it could wait for a commit. If a command is blocked waiting for a lock, how are you going to get a commit (you might get a rollback if the query is aborted)?