Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 95871632F50
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Thu, 11 Feb 2010 08:53:45 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia,
	port 10024)
	with ESMTP id 20834-05; Thu, 11 Feb 2010 12:53:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161])
	by mail.postgresql.org (Postfix) with SMTP id D25CB632E89;
	Thu, 11 Feb 2010 08:53:33 -0400 (AST)
Received: from source ([209.85.219.219]) by exprod7ob104.postini.com
	([64.18.6.12]) with SMTP
	ID DSNKS3P9y16O0gmz1k9xMxJr8AxuqD776ID2@postini.com;
	Thu, 11 Feb 2010 04:53:33 PST
Received: by ewy19 with SMTP id 19so1275569ewy.1
	for <multiple recipients>; Thu, 11 Feb 2010 04:53:31 -0800 (PST)
Received: by 10.213.1.151 with SMTP id 23mr581998ebf.34.1265892811184;
	Thu, 11 Feb 2010 04:53:31 -0800 (PST)
Received: from ?192.168.1.117? ([88.195.103.165])
	by mx.google.com with ESMTPS id 10sm5367873eyd.13.2010.02.11.04.53.29
	(version=TLSv1/SSLv3 cipher=RC4-MD5);
	Thu, 11 Feb 2010 04:53:29 -0800 (PST)
Message-ID: <4B73FDC8.3050208@enterprisedb.com>
Date: Thu, 11 Feb 2010 14:53:28 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Andres Freund <andres@anarazel.de>
CC: pgsql-hackers@postgresql.org, Simon Riggs <simon@2ndquadrant.com>,
	Tom Lane <tgl@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL
	(which was known for a little while
References: <20100208043355.412637541B9@cvs.postgresql.org>
	<1265883032.7341.1149.camel@ebony>
	<201002111204.10183.andres@anarazel.de>
In-Reply-To: <201002111204.10183.andres@anarazel.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.395 tagged_above=-10 required=5 tests=AWL=0.204,
	BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 201002/842
X-Sequence-Number: 157185

Andres Freund wrote:
> On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
>> On Mon, 2010-02-08 at 04:33 +0000, Tom Lane wrote:
>>> We still have to retain all code that copes with finding
>>> HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples.  This
>>> can't be removed as long as we want to support in-place update from
>>> pre-9.0 databases.
>> This doesn't seem to be a great reason. Letting weird states exist is
>> not a feature, its a risk. Let me explain.
>>
>> This would only happen if a VACUUM FULL had been run on the pre-9.0
>> database and it had failed part way through. Re-VACUUMing would remove
>> those settings.
>>
>> ISTM that that the upgrade process should cover this, not force the
>> server to cope with rare and legacy situations. If we do not do this,
>> then we might argue it should *never* be removed because this same rare
>> situation can persist into 9.1 etc..
>>
>> There were data loss situations possible in early 8.4 and these
>> persisted into later releases *because* the minor release upgrade
>> process did not contain a scan to detect and remove the earlier
>> problems. If we allow tuples to be in strange legacy states we greatly
>> increase the difficulty of diagnosing and fixing problems. People will
>> say "moved in/off can be ignored now" and mistakes will happen.
>>
>> We should remove the moved in/off flag bits and make it a part of the
>> upgrade process to ensure the absence of those states.
> Essentially requiring a successfull VACUUM FULL or CLUSTER on all tables is 
> imho in the same ballpark as requiring a dump+restore timewise on bigger 
> databases.

A plain VACUUM would be enough.

But FWIW, +1 from me for keeping the support for HEAP_IN/OUT in 9.0.
It's not a lot of code, and that way we don't need to invent some
safeguards in pg_migrator to check that there's no HEAP_IN/OUT flags
just yet.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com