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