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

On Thu, Feb 11, 2010 at 2:03 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
>> On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > Avoiding a scan before running pg_upgrade is just a performance
>> > optimisation.
>>
>> But using pg_upgrade AT ALL is also a performance optimization; in
>> fact AFAICS it's the only reason to use pg_upgrade.  So if you take
>> that away there's no reason to use it at all.
>
> I understand that the final process to switch from one release to
> another needs to be quick. Before that we can have any number of
> preparatory steps. One of those is backup, if you're sane. Another one
> should be a preparatory step that can be performed while the database is
> still on-line that checks that everything is in a good state for
> upgrade. No corruptions, no weird flags, everything good.
>
> If that last step is part of all upgrade procedures, including both
> minor and major we will all be happier and healthier. And the server can
> depend on that check and doesn't need to check itself for those
> weirdnesses from an earlier era.

That's a good point. I think we're going to keep running across
situations where we'd like to have a way of verifying that a
particular invariant holds for every page of a given relation. With
the infrastructure that we have now, we're going to be stuck with the
MOVED_xxx bits essentially forever. When we got to release 9.5, we
still won't be able to drop this code, because there could be someone
who used pg_upgrade to go from 8.3 or 8.4 to 9.0 and then to 9.1 and
then to 9.2 and then to 9.3 and then to 9.4 and now wants to go to
9.5.

I'm not quite sure how to do this in practice. One idea would be to
record the catversion that created the relation in pg_class, and make
pg_upgrade preserve the catversion, but make CLUSTER or similar bump
it on successful completion. But I'm not sure if that covers all the
cases we care about, or if requiring CLUSTER is too intrusive.

I think it's probably too late to work on this for 9.0, but it would
be nice to get it done for 9.1 so that we can make a long-term plan to
phase things like this out without relying on making statements like
"if before you pg_upgrade'd your database X times it was originally
from version X or earlier, and if you ever vacuum full'd it and any of
those tuples are still around, you might have a problem - but we can't
tell you whether that's the case or not."

...Robert