X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 7E90B52C10; Fri, 19 Aug 2005 15:55:38 -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 00296-01; Fri, 19 Aug 2005 18:55:34 +0000 (GMT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by svr1.postgresql.org (Postfix) with ESMTP id B330852B46; Fri, 19 Aug 2005 15:55:32 -0300 (ADT) Received: from cookie.varlena.com (64-142-36-103.dsl.static.sonic.net [64.142.36.103]) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7JItRCm010562; Fri, 19 Aug 2005 11:55:27 -0700 Received: by cookie.varlena.com (Postfix, from userid 1000) id C8B2CCCE; Fri, 19 Aug 2005 11:55:19 -0700 (PDT) Date: Fri, 19 Aug 2005 11:55:19 -0700 To: pgsql-interfaces@postgresql.org Cc: Junaili Lie , pgsql-general@postgresql.org, elein Subject: Re: in transaction Message-ID: <20050819185519.GY5365@varlena.com> Mail-Followup-To: pgsql-interfaces@postgresql.org, Junaili Lie , pgsql-general@postgresql.org References: <8d04ce990508181616c93fbbc@mail.gmail.com> <20050819000218.GS5365@varlena.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050819000218.GS5365@varlena.com> User-Agent: Mutt/1.5.6+20040907i From: elein@varlena.com (elein) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.057 required=5 tests=[AWL=0.007, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200508/1056 X-Sequence-Number: 82464 I'm cross posting to INTERFACES. Please follow up on INTERFACES and not on general. Cross posting is evil. --elein On Thu, Aug 18, 2005 at 05:02:18PM -0700, elein wrote: > I am also seeing this situation using hibernate. > > Some of the IDLE-in-transaction connections are sitting > there holding locks which is a BIG problem. > > The query I use to see the processes and locks is this: > > select procpid, usename , (now() - query_start) as age, > c.relname , l.mode, l.granted > from pg_stat_activity a LEFT OUTER JOIN pg_locks l ON (a.procpid = l.pid) > LEFT OUTER JOIN pg_class c ON (l.relation = c.oid) > where (current_query = ' in transaction' > or current_query like '%vacuum%') > -- and query_start < now() - '1 hours'::interval > order by pid; > > Note the commented out part. Change the interval to what you like. > You cannot see a query because there is none. > > Some of these I-i-t connections come and go after a while. > Some stick around for DAYS. > > If ANYONE has any brilliant ideas as to the source and > dare I say correction to this problem, many people, especially > myself would be very very happy. > > --elein > -------------------------------------------------------------- > elein@varlena.com Varlena, LLC www.varlena.com > (510)655-2584(o) (510)543-6079(c) > > PostgreSQL Consulting, Support & Training > > PostgreSQL General Bits http://www.varlena.com/GeneralBits/ > -------------------------------------------------------------- > AIM: varlenallc Yahoo: AElein Skype: varlenallc > -------------------------------------------------------------- > I have always depended on the [QA] of strangers. > > > > On Thu, Aug 18, 2005 at 04:16:27PM -0700, Junaili Lie wrote: > > Hi, > > We have applications that sits on top of Java application server. Our > > code is written in Java, sitting on top of Jboss with Hibernate, and > > we use JDBC driver pg74.215.jdbc2ee.jar. We have observed a number of > > in transaction on pg_stat_activity. > > I am wondering if there's command/view/system tables/ tools out there > > that will allow us to look at what's the in transactions that are > > waiting to be committed. > > We have some " in transaction" and would like to see which part > > of the code that causes it. > > > > > > Thanks in advance. > > > > J > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: don't forget to increase your free space map settings > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >