Tom Lane wrote: > The system tables are not the problem. pg_upgrade has shown how we > can have cross-version upgrades no matter how much the system catalogs > change (a good thing too, because we cannot freeze the system catalog > layout without bringing development to a standstill). A schema-only > dump and restore is cheap enough that there's no real reason to look > for any other solution. > > Changes in the on-disk representation of user tables would be harder to > deal with, but they are also much rarer (AFAIR we've only done that > twice: WAL required additions to page and tuple headers, and then there > were Manfred's space-saving changes in 7.3). And as of 7.3 there is a > version field in page headers, which would in theory allow for a > page-at-a-time update process to work. > > There isn't any fundamental reason why we cannot have a pg_upgrade > utility; claiming that there is something wrong with how we handle > catalog changes misses the point. The point is that *someone would > have to do the work*. Unless someone wants to step up and volunteer, > there's little value in discussing it.
pg_upgrade does work, assuming there are no changes to the index or heap file formats. (However, I now need to update it for schemas.) However, the last time I worked on it for 7.2, no one was really interested in testing it, so it never got done. In fact, there was a bug in the handling of clog or wal files, but I didn't find out about it until long after 7.2 because no one was using it. Is pg_upgrade too hard to run? Is no one really interested in it? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
