Re: pg_upgrade (was: 8.2 features status)

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Proposal C - PITR with in on the fly disk upgrades
>> 1) setup PITR
>> 2) run pg_upgrade on your latest backed up data directories
>> 3) start up the new pg on that data directory in restartable
>> recovery / read-only / hot-standby mode
>> 4) update the recovery log importer so that it can update the log
>> files on the fly as it applies them
>> 5) failover to the hot standby as you normally would

> I don't think this is practical. Simon?

I don't think there is very much hope of an in-place upgrade for
scenarios involving changes in contents of user tables. In particular,
what of a change that requires more space than before, such as adding a
locale indicator to text fields? There's no guarantee that the data on
an old page will still fit, and there's certainly no hope of something
operating at the xlog level being able to move tuples across pages ---
if nothing else, because it's not in a position to compute new index
entries. I don't see this working for page-at-a-time updates even in a
full backend environment; again, indexes are the killer consideration.
I don't see how to get sane behavior from an index containing some
old-style entries and some new-style ones for a changed datatype.

As you mentioned, the scenarios that look practical for in-place upgrade
are the ones where only system catalog contents need to change. We've
already discussed this (many times) and agreed that we could live with
restricting user-table changes to happen only once every few releases.

regards, tom lane