Skip site navigation (1) Skip section navigation (2)

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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>,Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Date: 2010-02-11 20:08:52
Message-ID: 20100211200852.GJ3145@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Boszormenyi ZoltanDate: 2010-02-11 20:09:06
Subject: Re: [PATCH] Provide rowcount for utility SELECTs
Previous:From: Boszormenyi ZoltanDate: 2010-02-11 20:00:56
Subject: Re: [PATCH] Provide rowcount for utility SELECTs

pgsql-committers by date

Next:From: Tom LaneDate: 2010-02-11 20:32:32
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Previous:From: Robert HaasDate: 2010-02-11 19:58:01
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group