Robert Haas escribió: > On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera > <alvhe...@commandprompt.com> wrote: > > Robert Haas escribió: > > > >> I'm not quite sure how to do this in practice. One idea would be to > >> record the catversion that created the relation in pg_class, and make > >> pg_upgrade preserve the catversion, but make CLUSTER or similar bump > >> it on successful completion. But I'm not sure if that covers all the > >> cases we care about, or if requiring CLUSTER is too intrusive. > > > > Wouldn't a table-wide vacuum remove those hint bits too? If so, just > > letting the database live for a bit would get rid of them. > > > > ... it seems it doesn't, but I wonder why can't we just patch > > heap_freeze_tuple to unset HEAP_MOVED if they are seen set and the > > VACUUM FULL transaction is no longer running. In fact, it seems silly > > not to. > > Well the issue is that it's not enough to get rid of them; we need a > way for pg_migrator to be certain that they're all gone.
Oh, I was just pointing out that if we were to add a catversion column to the table, it could be fixed by a simple complete vacuum -- no need for something heavy like CLUSTER. So to upgrade from 8.4 to 9.1 you could first upgrade to 9.0, then run VACUUM on all your tables, then upgrade to 9.1. > Now, the issue is that for some types of modifications, VACUUM might > be sufficient; others might require CLUSTER; still others might (I > suppose) require some other treatment still - like, say, regular > VACUUM but with some option to force every page to be scanned. So we > might find that for an upgrade from 9.3 to 9.4 you just need a regular > VACUUM; unless the relation originally came from 9.2 or earlier, in > which case you need a VACUUM that doesn't skip any pages; but if the > relation originally came from 8.4 or earlier, then you actually need > CLUSTER. Or whatever the case may be. Recording some bookkeeping > information in pg_class so that pg_migrator can tell what's going on > at a glance seems like the right approach, but I'm fuzzy on the > details. Maybe a bitmap of stuff that was applied to the table, where bit 1 means vacuum, bit 2 means space reservation, bit 3 means CRC added, and so on. "relflags", so to speak ... ? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
