Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Robert Haas escribió:
> On Thu, Feb 11, 2010 at 2:46 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)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