Why not go the other way.
1) Dump the schemas.
2) Initdb with the new schemas in a tmp PGDATA
3) backup the schemas in the current PGDATA
4) move the new schemas from the new db into the current one.
This means that doing an update you would only have to have space for
the system catalogs not the whole database.
How about a postmaster switch to point to the location of the system
catalogs files separate from the data files ?
On Fri, 2003-12-12 at 16:14, Thomas Swan wrote:
> Matthew T. O'Connor wrote:
>
> >On Fri, 2003-12-12 at 15:42, Tom Lane wrote:
> >
> >
> >>Alternative thought: just recommend that if possible, people take
> >>a filesystem dump of their old PGDATA directory after stopping
> >>the old postmaster. This would be sufficient for retreating to
> >>the prior version if needed. It might or might not be slower
> >>than copying all the files to a new PGDATA ...
> >>
> >>
> >
> >Certainly the easier path code wise :-) Being the belt, suspenders and
> >steel tip boots (foot gun protection) type that I am, I would make a
> >backup even if pg_upgrade copies all the data files. Having pg_upgrade
> >copy the data files give you an extra layer of protection if desired,
> >and can possibly save an admin who fails to get a good backup of the old
> >PGDATA for what ever reason.
> >
> >
> >
> I'd be in favor of a prompt at the beginning of the script. "Have made
> a copy of the PGDATA directory?" If answered no, then ask for a
> confirmation to proceed without backup? To skip the prompt have an
> option for '--skip-prompt' for those who are a little more sure of
> themselves or want to write a more automated script for this process.
>
> This approach gives more flexibility as there may not be sufficient
> storage available for double the existing database size for conversion
> on that mount point / disk. The admin doing the upgrade can copy the
> existing database wherever they need it: tape, another filesystem, NFS
> mount, etc.
>
> --
> Thomas Swan
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Dave Smith
CANdata Systems Ltd
416-493-9020