On Wed, Dec 2, 2009 at 2:27 PM, Greg Smith <g...@2ndquadrant.com> wrote: > Robert Haas wrote: > > On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith <g...@2ndquadrant.com> wrote: > > > There's no reason the associated catalog support had to ship with the old > version. You can always modify the catalog after initdb, but before running > the pre-upgrade utility. pg_migrator might make that change for you. > > > Uh, really? I don't think that's possible at all. > > > Worst case just to get this bootstrapped: you install a new table with the > added bits. Old version page upgrader accounts for itself there. > pg_migrator dumps that data and then loads it into its new, correct home on > the newer version. There's already stuff like that being done > anyway--dumping things from the old catalog and inserting into the new > one--and if the origin is actually an add-on rather than an original catalog > page it doesn't really matter. As long as the new version can see the info > it needs in its catalog it doesn't matter how it got to there; that's the > one that needs to check the migration status before it can access things > outside of the catalog.
That might work. I think that in order to get a fixed OID for the new catalog you would need to run a backend in bootstrap mode, which might (not sure) require shutting down the database first. But it sounds doable. There remains the issue of whether it is reasonable to think about backpatching such a thing, and whether doing so is easier/better than dealing with page expansion in the new server. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
