Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id A5BF49FB955 for ; Wed, 16 May 2007 17:35:48 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 36800-10 for ; Wed, 16 May 2007 17:35:44 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by postgresql.org (Postfix) with ESMTP id BFA499FBAB9 for ; Wed, 16 May 2007 17:35:44 -0300 (ADT) Received: by an-out-0708.google.com with SMTP id d17so75523and for ; Wed, 16 May 2007 13:35:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=gqGh3aKgJv6VUX+WwLe2bGyZje4xAlTfIKhWWW8WHEtP5NnKcU011DraUYKtHUCf06RPMbPlJf2W4f52smdUfht/KqkS+nTvRj+8e6l4rP05bsVP1314uXf+vP/oWEvRdoho1e9tt5UngjvnzkooesNhQSP0Xs9kclUP866ubfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=OLUVVouXLFPVIzTQnfTQR2Sn+FWsimuRM0L71qXY4xAfHi6b2oNtcmex0aW+qDpmDVj54jAGxQ8cXawh9nyOm8WH43Z32XhFjLyuw+KTgXnPd06tiwvWcHgnRouSTqrkkmsoKKOgBkn3wcuA/4LKTNZUhW3w7lkcAo1mFUpsd/M= Received: by 10.100.39.18 with SMTP id m18mr3248082anm.1179347743044; Wed, 16 May 2007 13:35:43 -0700 (PDT) Received: from ?192.168.1.33? ( [82.3.78.153]) by mx.google.com with ESMTP id c13sm2244208anc.2007.05.16.13.35.36; Wed, 16 May 2007 13:35:40 -0700 (PDT) Message-ID: <464B6B08.6030609@enterprisedb.com> Date: Wed, 16 May 2007 21:35:20 +0100 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Tom Lane CC: Alvaro Herrera , Chris Browne , pgsql-patches@postgresql.org Subject: Re: [DOCS] Autovacuum and XID wraparound References: <20070514011740.GH14860@fetter.org> <23394.1179108400@sss.pgh.pa.us> <1179117269.6047.3.camel@goldbach> <60sl9z6tln.fsf@dba2.int.libertyrms.com> <20070514221619.GC8916@alvh.no-ip.org> <857.1179184222@sss.pgh.pa.us> <20070515221347.GT12731@alvh.no-ip.org> <23362.1179292856@sss.pgh.pa.us> <20070516124420.GA4582@alvh.no-ip.org> <464B0E5A.1070807@enterprisedb.com> <6549.1179344646@sss.pgh.pa.us> <464B60A7.3070106@enterprisedb.com> <7145.1179347418@sss.pgh.pa.us> In-Reply-To: <7145.1179347418@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/254 X-Sequence-Number: 2354 Tom Lane wrote: > It's removing potentially-important data without any notice or recourse > to the user. There seems to be a contingent around here that thinks > that as soon as xmin is older than GlobalXmin it is no longer of > interest to anyone, but I have lost count of how often I have found it > invaluable for forensic purposes. I have resisted having VACUUM freeze > tuples before they've reached a quite-respectable age, and I object to > having CLUSTER do it either. How about freezing anything older than vacuum_freeze_min_age, just like VACUUM does? > I could maybe accept a CLUSTER FREEZE option to do this, but that's not > what's in the patch. I wouldn't like to add more options to CLUSTER, people are already confused about the similar VACUUM options. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com