Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 74E7313C699A for ; Fri, 4 May 2012 12:06:12 -0300 (ADT) Received: from mh7.mail.rice.edu ([128.42.199.46]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SQK5A-0007Xx-A5 for pgsql-admin@postgresql.org; Fri, 04 May 2012 15:06:11 +0000 Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id 1096029211D; Fri, 4 May 2012 10:05:54 -0500 (CDT) Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id ECD66292119; Fri, 4 May 2012 10:05:53 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh7.mail.rice.edu, auth channel Received: from mh7.mail.rice.edu ([127.0.0.1]) by mh7.mail.rice.edu (mh7.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 1GqHU40BEA10; Fri, 4 May 2012 10:05:53 -0500 (CDT) X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no Received: from aart.rice.edu (aart.rice.edu [168.7.56.48]) by mh7.mail.rice.edu (Postfix) with ESMTP id B1F1B292116; Fri, 4 May 2012 10:05:53 -0500 (CDT) Received: by aart.rice.edu (Postfix, from userid 18612) id A7402100589; Fri, 4 May 2012 10:05:53 -0500 (CDT) Date: Fri, 4 May 2012 10:05:53 -0500 From: "ktm@rice.edu" To: Kevin Grittner Cc: pgsql-admin@postgresql.org, 'Albe Laurenz' Subject: Re: Very long " in transaction" query Message-ID: <20120504150553.GL32303@aart.rice.edu> References: <008101cd2916$1c023b20$5406b160$@com> <008001cd29db$ab24ba60$016e2f20$@com> <20120504133842.GH32303@aart.rice.edu> <4FA399E40200002500047870@gw.wicourts.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA399E40200002500047870@gw.wicourts.gov> User-Agent: Mutt/1.5.20 (2009-12-10) X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/29 X-Sequence-Number: 39518 On Fri, May 04, 2012 at 08:57:08AM -0500, Kevin Grittner wrote: > "ktm@rice.edu" wrote: > > > You may also want to consider setting a statement_timeout to > > prevent this until you can find the problem with the application. > > How would a statement timeout help close a transaction on an idle > connection? It's idle because no statements are being run. > > -Kevin Yes, you are correct. I misunderstood. Too bad we do not have a transaction_timeout. Regards, Ken