From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Date: Thu, 11 Feb 2010 14:53:28 +0200
Message-ID: <4B73FDC8.3050208@enterprisedb.com> (raw)
In-Reply-To: <201002111204.10183.andres@anarazel.de>
References: <20100208043355.412637541B9@cvs.postgresql.org>
<1265883032.7341.1149.camel@ebony>
<201002111204.10183.andres@anarazel.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, andres@anarazel.de, simon@2ndquadrant.com, tgl@postgresql.org
Subject: Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
In-Reply-To: <4B73FDC8.3050208@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox