Received: from localhost (unknown [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id 041489FA473
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 31 Aug 2007 15:31:59 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
	with ESMTP id 86896-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 31 Aug 2007 15:31:52 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from nz-out-0506.google.com (nz-out-0506.google.com
 [64.233.162.227])
	by postgresql.org (Postfix) with ESMTP id E030E9FA3A9
	for <pgsql-performance@postgresql.org>;
	Fri, 31 Aug 2007 15:31:53 -0300 (ADT)
Received: by nz-out-0506.google.com with SMTP id l8so603983nzf
	for <pgsql-performance@postgresql.org>;
	Fri, 31 Aug 2007 11:31:52 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=B596INQDYme2+cxpY2su1O+YNSCJAdNNmIABHT2+4kIewZk5W8rzqOKcbGISiQmX3blaWOAofJOTOxlOSKvj9cruB4vjjsYE50ndhZquaw8j5FKeC2T04vhh39ASwvrES8xPnvI5cMvSDJQNg7uE2yqacanetQ7bWUpAgOfj4Cc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=BxENbTaQfIFx8gAUyrseTlZq8lPTx6B5hGUEn9kkCQh5MTavXGiSrn2Oi4UY9o4uHuvUaToMM4rBZwOZ4i/s9XMoC2iFxKzay+l17BjNYuq59SnD+i/RIJZ5j/55bRQFee7nUN7uXUbBNb14K56pklXb43IFtbdagQ0HzmkQDB0=
Received: by 10.115.109.1 with SMTP id l1mr7758wam.1188585107919;
	Fri, 31 Aug 2007 11:31:47 -0700 (PDT)
Received: by 10.114.92.5 with HTTP; Fri, 31 Aug 2007 11:31:47 -0700 (PDT)
Message-ID: <2ca799770708311131r5ae5e3eera66a7cea1fc5917d@mail.gmail.com>
Date: Fri, 31 Aug 2007 21:31:47 +0300
From: "Mikko Partio" <mpartio@gmail.com>
To: "Alvaro Herrera" <alvherre@commandprompt.com>
Subject: Re: 8.2 Autovacuum BUG ?
Cc: "Pallav Kalva" <pkalva@livedatagroup.com>, "Tom Lane" <tgl@sss.pgh.pa.us>,
	pgsql-performance@postgresql.org
In-Reply-To: <20070831161158.GD8046@alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11622_11327253.1188585107804"
References: <46D83427.60001@livedatagroup.com>
 <25038.1188574775@sss.pgh.pa.us>
	<46D83C50.3040409@livedatagroup.com>
	<20070831161158.GD8046@alvh.no-ip.org>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200708/403
X-Sequence-Number: 26533

------=_Part_11622_11327253.1188585107804
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 8/31/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
>
> Pallav Kalva wrote:
> > Tom Lane wrote:
>
> >> Probably represents freezing of old tuples, which is a WAL-logged
> >> operation as of 8.2.  Is it likely that the data is 200M transactions
> >> old?
> >>
> > If nothing changed on these tables how can it freeze old tuples ?
> > Does it mean that once it reaches 200M transactions it will do the same
> > thing all over again ?
>
> No -- once tuples are frozen, they don't need freezing again (unless
> they are modified by UPDATE or DELETE).
>
>

Off-topic question: the documentation says that XID numbers are 32 bit.
Could the XID be 64 bit when running on a 64 bit platform? That would
effectively prevent wrap-around issues.

Regards

MP

------=_Part_11622_11327253.1188585107804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 8/31/07, <b class="gmail_sendername">Alvaro Herrera</b> &lt;<a href="mailto:alvherre@commandprompt.com">alvherre@commandprompt.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Pallav Kalva wrote:<br>&gt; Tom Lane wrote:<br><br>&gt;&gt; Probably represents freezing of old tuples, which is a WAL-logged<br>&gt;&gt; operation as of 8.2.&nbsp;&nbsp;Is it likely that the data is 200M transactions<br>&gt;&gt; old?
<br>&gt;&gt;<br>&gt; If nothing changed on these tables how can it freeze old tuples ?<br>&gt; Does it mean that once it reaches 200M transactions it will do the same<br>&gt; thing all over again ?<br><br>No -- once tuples are frozen, they don&#39;t need freezing again (unless
<br>they are modified by UPDATE or DELETE).<br><br></blockquote></div><br><br>Off-topic question: the documentation says that XID numbers are 32 bit. Could the XID be 64 bit when running on a 64 bit platform? That would effectively prevent wrap-around issues.
<br><br>Regards<br><br>MP<br>

------=_Part_11622_11327253.1188585107804--