Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 1350EC4CD78 for ; Thu, 3 May 2012 08:19:19 -0300 (ADT) Received: from mout2.freenet.de ([2001:748:100:40::2:4]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SPu45-00018X-9W for pgsql-admin@postgresql.org; Thu, 03 May 2012 11:19:18 +0000 Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout2.freenet.de with esmtpa (ID jan.lentfer@freenet.de) (port 25) (Exim 4.76 #1) id 1SPu3r-0003su-Bz for pgsql-admin@postgresql.org; Thu, 03 May 2012 13:19:03 +0200 Received: from localhost ([::1]:48836 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID jan.lentfer@freenet.de) (Exim 4.76 #1) id 1SPu3r-00087z-8D for pgsql-admin@postgresql.org; Thu, 03 May 2012 13:19:03 +0200 Received: from [195.4.92.11] (port=32970 helo=1.mx.freenet.de) by mjail0.freenet.de with esmtpa (ID jan.lentfer@freenet.de) (Exim 4.76 #1) id 1SPu12-0006nt-DB for pgsql-admin@postgresql.org; Thu, 03 May 2012 13:16:08 +0200 Received: from p579b7703.dip.t-dialin.net ([87.155.119.3]:55131 helo=epia.lan.net) by 1.mx.freenet.de with esmtpa (ID jan.lentfer@freenet.de) (port 25) (Exim 4.76 #1) id 1SPu12-0003Mk-85 for pgsql-admin@postgresql.org; Thu, 03 May 2012 13:16:08 +0200 Received: from localhost (localhost [127.0.0.1]) by epia.lan.net (Postfix) with ESMTP id A797A26A7BDFA for ; Thu, 3 May 2012 13:16:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at lan.net Received: from epia.lan.net ([127.0.0.1]) by localhost (epia.lan.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPU3N+dWgoay for ; Thu, 3 May 2012 13:15:41 +0200 (CEST) Received: from neslonek.homeunix.org (localhost [127.0.0.1]) by epia.lan.net (Postfix) with ESMTP id 68D2B26A7BD47 for ; Thu, 3 May 2012 13:15:39 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 May 2012 13:15:37 +0200 From: Jan Lentfer To: Subject: Re: Very long " in transaction" query In-Reply-To: <008101cd2916$1c023b20$5406b160$@com> References: <008101cd2916$1c023b20$5406b160$@com> Message-ID: X-Sender: Jan.Lentfer@web.de User-Agent: RoundCube Webmail/0.5.3 X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/14 X-Sequence-Number: 39503 On Thu, 3 May 2012 15:48:35 +0530, Gnanakumar wrote: > Hi, > > Recently, in our Production server, we found a "single query" being > held up > in " in transaction" for more than 19 hours using the following > query: [...] Usually these are application problems, not database ones. E.g. a piece of code not cathing an error correctly or breaking out of a loop or something like that and leaving the transaction open (not issuing COMMIT or ROLLBACK). Seens this quite often in production and it was always tracebla back to an application error. To find out what the session has last done before it started idling you would need to turn on statement logging. Then at least you might be able to trace down in which part of you application this was caused. Jan -- professional: http://www.oscar-consult.de private: http://neslonek.homeunix.org/drupal/