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
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
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-02-11 13:01:25|
|Subject: Re: knngist patch support|
|Previous:||From: Bart Samwel||Date: 2010-02-11 12:48:14|
|Subject: Re: Avoiding bad prepared-statement plans.|
pgsql-committers by date
|Next:||From: Simon Riggs||Date: 2010-02-11 13:06:39|
|Subject: Re: Re: [COMMITTERS] pgsql: Make standby server
continuously retry restoring the next WAL|
|Previous:||From: Heikki Linnakangas||Date: 2010-02-11 12:44:09|
|Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously
retry restoring the next WAL|