On Tue, Feb 16, 2010 at 2:04 PM, Bruce Momjian <bruce@momjian.us> wrote:
> The MOVE_* bits go away after a while by vacuum and there is an easy
> solution for 9.1 --- vacuum everything in 9.0. Where things really get
> hard is when we have to support two page formats or two data formats in
> the same database. You might think we will never get there, but there
> have been such changes in the past, and I suspect that we will have them
> in the future, maybe not in 9.1, but perhaps 9.3.
I think a O(size of database) step in the upgrade process is
acceptable iff it can be performed while the database is operational.
In this case that would mean having some code in 8.4.3 to prevent
VACUUM FULL from being used once a flag indicating that a migration is
under way. Then you would have to vacuum every table which would set a
flag indicating that no MOVED_* bits were set. Then pg_migrator would
check that that flag was set on every table before allowing you to
migrate.
This might actually be a reasonable thing to put in 9.0. We already
have the code to prevent you from running VACUUM FULL -- namely that
it doesn't exist any longer. And I think we can tell whether there are
any MOVED_* bits set by looking at the vacuum freeze age of the table.
The only thing we're missing is the youngest xid seen in 8.4 before
the 9.0 migration.
--
greg