Greg Stark wrote: > 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.
That might work for this case, but I think long-term we will need to do such changes in the _next_ major release, and add some mechanism that pg_migrator could test to know that the old format is gone. I don't think backpatching to minor releases is really sustainable. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
