Greg Stark wrote:
> 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.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
