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: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(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 13:22:28
Message-ID: 1265894548.7341.1521.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Thu, 2010-02-11 at 14:53 +0200, Heikki Linnakangas wrote:
> Andres Freund wrote:
> > On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
> >> We should remove the moved in/off flag bits and make it a part of the
> >> upgrade process to ensure the absence of those states.
> > Essentially requiring a successfull VACUUM FULL or CLUSTER on all tables is 
> > imho in the same ballpark as requiring a dump+restore timewise on bigger 
> > databases.
> 
> A plain VACUUM would be enough.

Yes

> But FWIW, +1 from me for keeping the support for HEAP_IN/OUT in 9.0.
> It's not a lot of code, and that way we don't need to invent some
> safeguards in pg_migrator to check that there's no HEAP_IN/OUT flags
> just yet.

The amount of code has nothing to do with keeping it or removing it.

Requiring the backend to support something just because an external
utility wants to optimise the performance of upgrades in a way that may
introduce later bugs seems rather questionable to me.

You still have to perform a backup of the database prior to upgrade and
that also must scan the whole database, so the overall time to upgrade
will still vary according to database size. So I don't see any overall
benefit, just risk, and I cited a similar situation where that risk has
already materialized into damage for a user in at least one case.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-02-11 13:28:51
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Robert HaasDate: 2010-02-11 13:18:23
Subject: Re: knngist patch support

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2010-02-11 13:28:51
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Simon RiggsDate: 2010-02-11 13:06:39
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

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