Subject: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was
	known for a little while
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@postgresql.org>
Cc: pgsql-hackers@postgresql.org
In-Reply-To: <20100208043355.412637541B9@cvs.postgresql.org>
References: <20100208043355.412637541B9@cvs.postgresql.org>
Content-Type: text/plain
Date: Thu, 11 Feb 2010 10:10:32 +0000
Message-Id: <1265883032.7341.1149.camel@ebony>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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.

-- 
 Simon Riggs           www.2ndQuadrant.com