X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 816DE53646 for ; Thu, 14 Apr 2005 16:04:54 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 35866-08 for ; Thu, 14 Apr 2005 19:04:53 +0000 (GMT) Received: from sunsite.dcc.uchile.cl (sunsite.dcc.uchile.cl [192.80.24.2]) by svr1.postgresql.org (Postfix) with ESMTP id 9B5BD53B6A for ; Thu, 14 Apr 2005 16:04:52 -0300 (ADT) Received: from anakena.dcc.uchile.cl (anakena [192.80.24.6]) by sunsite.dcc.uchile.cl (8.12.11/8.12.11) with ESMTP id j3EJ4lW1019250; Thu, 14 Apr 2005 15:04:47 -0400 (CLT) Received: by anakena.dcc.uchile.cl (Postfix, from userid 4151) id DC6EE52B67; Thu, 14 Apr 2005 15:04:47 -0400 (CLT) Date: Thu, 14 Apr 2005 15:04:47 -0400 From: Alvaro Herrera To: Andrew Sullivan Cc: pgsql-sql@postgresql.org Subject: Re: row-attribute in EXPLAIN-output doesn't match count(*) Message-ID: <20050414190447.GE28198@dcc.uchile.cl> References: <200504141838.14705.andreak@officenet.no> <200504141921.38476.andreak@officenet.no> <20050414173358.GB9027@phlogiston.dyndns.org> <200504141954.20520.andreak@officenet.no> <20050414185623.GC9027@phlogiston.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050414185623.GC9027@phlogiston.dyndns.org> User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.344 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE X-Spam-Level: X-Archive-Number: 200504/208 X-Sequence-Number: 21101 On Thu, Apr 14, 2005 at 02:56:23PM -0400, Andrew Sullivan wrote: > On Thu, Apr 14, 2005 at 07:54:19PM +0200, Andreas Joseph Krogh wrote: > > Any hints on how I can find out what's keeping the connection idle in a > > transaction? I realize now that I should probably ask that question on the > > pgsql-jdbc-list:-) > > Nope. That's a problem with your pool software. It's no doubt > issuing "BEGIN;" as soon as it connects. It's BAD (broken as > designed) in that case. You need to convince it not to do that, or > else you need to go around and kill -2 such connections from time to > time. It is a Postgres limitation as well. We _could_ make the server "really start the transaction" at the point the first query is issued instead of when the BEGIN is issued. In fact this problem would go away if we did that. -- Alvaro Herrera () Voy a acabar con todos los humanos / con los humanos yo acabaré voy a acabar con todos / con todos los humanos acabaré (Bender)