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: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 11:04:07
Message-ID: 201002111204.10183.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
> On Mon, 2010-02-08 at 04:33 +0000, Tom Lane wrote:
> > We still have to retain all code that copes with finding
> > HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples.  This
> > can't be removed as long as we want to support in-place update from
> > pre-9.0 databases.
> 
> This doesn't seem to be a great reason. Letting weird states exist is
> not a feature, its a risk. Let me explain.
> 
> This would only happen if a VACUUM FULL had been run on the pre-9.0
> database and it had failed part way through. Re-VACUUMing would remove
> those settings.
> 
> ISTM that that the upgrade process should cover this, not force the
> server to cope with rare and legacy situations. If we do not do this,
> then we might argue it should *never* be removed because this same rare
> situation can persist into 9.1 etc..
> 
> There were data loss situations possible in early 8.4 and these
> persisted into later releases *because* the minor release upgrade
> process did not contain a scan to detect and remove the earlier
> problems. If we allow tuples to be in strange legacy states we greatly
> increase the difficulty of diagnosing and fixing problems. People will
> say "moved in/off can be ignored now" and mistakes will happen.
> 
> 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.

Andres

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-02-11 11:18:34
Subject: Re: Bugs in b-tree dead page removal
Previous:From: Bruce MomjianDate: 2010-02-11 11:03:08
Subject: Re: log_error_verbosity function display

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2010-02-11 12:22:16
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Simon RiggsDate: 2010-02-11 10:37:37
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