On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote: > Tom Lane <[EMAIL PROTECTED]> writes: > > > 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. > > What of having support in the backend for two heap formats in each version. > That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be > a flag in pg_class indicating the heap format for that heap. Then you would be > able to upgrade without rewriting all your tables and the only requirement is > that sometime prior to the next upgrade you issue a per-table ALTER TABLE that > involves rewriting the table such as CLUSTER or ALTER COLUMN TYPE USING. > > That still requires 2x space but only for a single table at a time which is > much better than 2x space for the entire database. It also lets you schedule > that job for some point in time when you can arrange to have the extra space.
Unless you make it so that the old-version pages get changed to the new version on-the-fly as they get dirtied. And please folks, yes, it's be insane to make the backend deal with more than one old version at a time. I think it's perfectly acceptable to tell folks that if they want to jump 4 major versions at once that they'll have to do it some other way. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
