> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers