Re: vacuumdb --freeze - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: vacuumdb --freeze
Date
Msg-id 1234950861.3973.20.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: vacuumdb --freeze  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Tue, 2009-02-17 at 18:52 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > I would like to add a --freeze parameter to vacuumdb for use by the
> > > binary upgrade utility, and for symmetry with the existing VACUUM
> > > options;  patch attached.
> > 
> > Exactly what do you think the upgrade utility is going to do with it?
> > Surely not a database-wide VACUUM FREEZE, if we are hoping that upgrade
> > is going to be fast.
> > 
> > As far as I can see this is a solution looking for a problem.
> 
> I didn't go into the use-case.  The way pg_migrator works is to copy the
> _schema_ from the old database and load it into the new database.  We
> then need to run vacuum freeze on the schema-only databases because we
> then move pg_clog from the old database to the new one; so, it is
> needed, and it will not take long to run.

So you don't actually want to VACUUM the whole database anyway, just the
system tables?

I'd like to see VACUUM SYSTEM, just like we have REINDEX SYSTEM. That
way you can then do a --freeze --system on vacuumdb, which is all you
want to do anyway.

If the code is there for REINDEX SYSTEM it should be pretty easy to move
it across to VACUUM. 

I've had times when I just wanted to VACUUM the catalog tables, so to go
through them all one by one is tedious and missing one isn't possible
with a special command.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Zeugswetter Andreas OSB sIT
Date:
Subject: Re: vacuumdb --freeze
Next
From: Thomas Hallgren
Date:
Subject: Re: [Pljava-dev] Re: Should creating a new base type require superuser status?