Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id CE5ABCE6EC for ; Fri, 15 Jun 2012 17:00:28 -0300 (ADT) Received: from gwmta.wicourts.gov ([165.219.244.99] helo=gw.wicourts.gov) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Sfch1-0000Ak-TQ for pgsql-performance@postgresql.org; Fri, 15 Jun 2012 20:00:28 +0000 Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Fri, 15 Jun 2012 15:00:15 -0500 Message-Id: <4FDB4DF602000025000484FE@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.2 Date: Fri, 15 Jun 2012 15:00:06 -0500 From: "Kevin Grittner" To: "Benedict Holland" Cc: Subject: Re: Update blocking a select count(*)? References: <4FDB3C0202000025000484E4@gw.wicourts.gov> <4FDB40B702000025000484EE@gw.wicourts.gov> <4FDB476A02000025000484F4@gw.wicourts.gov> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201206/92 X-Sequence-Number: 47118 Benedict Holland wrote: > Is it a bug that the blocking process reported is the finial > process but really the process blocking the intermediate? What reported that? The PostgreSQL server doesn't report such things directly, and I don't know pgadmin, so I don't know about that tool. I wrote the recursive query on this page: http://wiki.postgresql.org/wiki/Lock_dependency_information So if that reported anything incorrecly, please let me know so I can fix it. By the way, the example with the three connections would have been better had I suggested a BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; on the third connection. With that, even if one or both of the transactions on the other connections committed, the third transaction's count should remain unchanged. -Kevin