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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers