On Tue, Feb 16, 2010 at 2:04 PM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
