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: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, 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 12:53:28
Message-ID: 4B73FDC8.3050208@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Andres Freund wrote:
> 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.

A plain VACUUM would be enough.

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.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-11 13:01:25
Subject: Re: knngist patch support
Previous:From: Bart SamwelDate: 2010-02-11 12:48:14
Subject: Re: Avoiding bad prepared-statement plans.

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-02-11 13:06:39
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Heikki LinnakangasDate: 2010-02-11 12:44:09
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