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 B69A28B9B5D
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 22 Feb 2005 12:43:42 +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 46872-01
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 22 Feb 2005 12:43:33 +0000 (GMT)
Received: from unisoft.unisoftbg.com (unisoft.unisoftbg.com [194.12.229.193])
	by svr1.postgresql.org (Postfix) with SMTP id BDF0A8B9B33
	for <pgsql-sql@postgresql.org>; Tue, 22 Feb 2005 12:43:34 +0000 (GMT)
Received: (qmail 95208 invoked by uid 1011); 22 Feb 2005 12:48:18 -0000
Received: from pginfo@t1.unisoftbg.com by unisoft.unisoftbg.com by uid 1009
	with qmail-scanner-1.22-st-qms (clamdscan: 0.75. spamassassin: 2.60.
	Clear:RC:0(192.168.1.201):SA:0(-4.7/5.0):.
	Processed in 17.315326 secs); 22 Feb 2005 12:48:18 -0000
X-Antivirus-MYDOMAIN-Mail-From: pginfo@t1.unisoftbg.com via
	unisoft.unisoftbg.com
X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(192.168.1.201):SA:0(-4.7/5.0):.
	Processed in 17.315326 secs Process 95199)
Received: from unknown (HELO t1.unisoftbg.com)
	(pginfo@t1.unisoftbg.com@192.168.1.201)
	by unisoft.unisoftbg.com with SMTP; 22 Feb 2005 12:47:59 -0000
Message-ID: <421B1C3B.1020803@t1.unisoftbg.com>
Date: Tue, 22 Feb 2005 12:49:15 +0100
From: pginfo <pginfo@t1.unisoftbg.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Ragnar_Hafsta=F0?= <gnari@simnet.is>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Richard_D_Levine@raytheon.com,
	Michael Glaesemann <grzm@myrealbox.com>, pgsql-sql@postgresql.org
Subject: Re: pg primary key bug?
References: <OFEF67063C.F61988F3-ON05256F9D.005A91D6@ftw.us.ray.com>	
	<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>
	<1109073162.17839.124.camel@localhost.localdomain>
Content-Type: multipart/alternative;
	boundary="------------070607020907090208000903"
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=2.088 tagged_above=0 required=5 tests=AWL, HTML_40_50,
	HTML_MESSAGE, HTML_TITLE_EMPTY, RCVD_IN_XBL
X-Spam-Level: **
X-Archive-Number: 200502/237
X-Sequence-Number: 20348


--------------070607020907090208000903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit



Ragnar Hafstaš wrote:

>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
>
>  
>
Only to add,
also keeping sme transactions for long time not commited (possible).
regards,
ivan.

>
>
>  
>


--------------070607020907090208000903
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<br>
<br>
Ragnar Hafsta&eth; wrote:<br>
<blockquote type="cite"
 cite="mid1109073162.17839.124.camel@localhost.localdomain">
  <pre wrap="">On Tue, 2005-02-22 at 10:33 +0100, pginfo wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">  
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)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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

  </pre>
</blockquote>
Only to add,<br>
also keeping sme transactions for long time not commited (possible).<br>
regards,<br>
ivan.<br>
<blockquote type="cite"
 cite="mid1109073162.17839.124.camel@localhost.localdomain">
  <pre wrap="">


  </pre>
</blockquote>
<br>
</body>
</html>

--------------070607020907090208000903--