> for getting 8.4->8.5 upgrade into place. You should first work on an
> update process that supports catalog changes, and get that committed.
> Once that's in place you'll have enough political capital to prevent
> changes in user data layout, and then we'd start to think about schemes
> like space reservation that could relax that ground rule.
I agree that catalog changes are the best way to start. And I also
think it's important that this logic get written in C, primarily so
that it gets deeply integrated into core. When a patch submitter adds
a function like array_length and puts in the markup for the BKI, they
should also be responsible for adding the function to the list of
changes that the UIP code needs to make when upgrading from the
catversion of the previous release to the current catversion. If
upgrade in place consists of Zdenek running around during every beta
cycle trying to figure out everything that happened to get done during
that dev cycle, it's not going to work (especially if Zdenek gets hit
by a bus).
That implies a fairly robust and configurable system for adding to and
rewriting system catalogs, which today we haven't got. Once we do
have it, we can think about how to handle things like page layout
bumps and toast chunk changes. Frankly, with things as they are
today, there's no way I'm using pg_upgrade on my production system.
Even if the whole thing gets rewritten in perl, it's an ex post facto
attempt to catch up with a gazillion changes that got made without any
regard to whether they'd work with pg_upgrade. It seems very
difficult to be confident that this will be 100% correct...
...Robert
