On Wed, Dec 2, 2009 at 2:27 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Robert Haas wrote:
>
> On Wed, Dec 2, 2009 at 1:56 PM, Greg Smith <greg@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
