On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
<alvherre@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. And there
will be other things in the future that we may want to handle this
way: page format conversions, for example, say to add checksums. You
don't want to let people do the migration and then have the new
cluster choke after it's already in production.
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.
...Robert