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 A66F78B9BCA for ; Tue, 22 Feb 2005 11:51:36 +0000 (GMT) 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 30204-01 for ; Tue, 22 Feb 2005 11:51:30 +0000 (GMT) Received: from quasar.skima.is (quasar.skima.is [212.30.200.205]) by svr1.postgresql.org (Postfix) with ESMTP id 1F4028B9E9C for ; Tue, 22 Feb 2005 11:51:28 +0000 (GMT) Received: from gnari ([157.157.193.193] [157.157.193.193]) by quasar.skima.is with ESMTP; Tue, 22 Feb 2005 11:51:26 Z Subject: Re: pg primary key bug? From: Ragnar =?ISO-8859-1?Q?Hafsta=F0?= To: pginfo Cc: Tom Lane , Richard_D_Levine@raytheon.com, Michael Glaesemann , pgsql-sql@postgresql.org In-Reply-To: <421AFC7F.406@t1.unisoftbg.com> References: <4214B466.20908@t1.unisoftbg.com> <8125.1108661189@sss.pgh.pa.us> <4214C94F.2050806@t1.unisoftbg.com> <9340.1108664352@sss.pgh.pa.us> <4214D5C3.4070107@t1.unisoftbg.com> <9785.1108666900@sss.pgh.pa.us> <421992FE.3030108@t1.unisoftbg.com> <3293.1109026294@sss.pgh.pa.us> <421AC251.7060806@t1.unisoftbg.com> <7012.1109061770@sss.pgh.pa.us> <421AFC7F.406@t1.unisoftbg.com> Content-Type: text/plain Date: Tue, 22 Feb 2005 11:52:42 +0000 Message-Id: <1109073162.17839.124.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200502/236 X-Sequence-Number: 20347 On Tue, 2005-02-22 at 10:33 +0100, pginfo wrote: > > > We are using jdbc (jdbc driver from pg) + jboss (java based > application server) + connection pool (biult in jboss). > ... > Will vacuum full generate this problem if we have locked table in this > time? (It is possible to have locked table in theory) I do not know if this is relevant, but I have seen jboss applications keep sessions in 'Idle in transaction' state, apparently with some locks granted. Would such cases not interfere with vacuum? gnari