Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while
Date: 2010-02-11 10:10:32
Message-ID: 1265883032.7341.1149.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

--
Simon Riggs www.2ndQuadrant.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2010-02-11 10:37:37 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous Message User H-saito 2010-02-11 04:46:30 psqlodbc - psqlodbc: Addition changes.

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-02-11 10:34:56 Re: Parameter name standby_mode
Previous Message Magnus Hagander 2010-02-11 09:18:46 Re: TCP keepalive support for libpq