On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote:
> On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote:
> > The big change was from 6.x to 7.x where a chunk of data moved from end
> > of page to start of page and tableoid column was added. Otherways the
> > table structure is quite simple. The difficulties with user _data_ can
> > be mainly because of binary format changes for some types and such.
> >
> > But I still can't see how will having a binary dumper that does mostly
> > the work of [ old_backend -c "COPY tablex TO STDOUT" ] help us here.
> >
> > IIRC the main difficulties in upgrading have always been elsewhere, like
> > migrating always changing system table data.
>
> The main problem is getting access to the user data after an upgrade.
Can't it be dumped in pre-upgrade script ?
> There's no particular problem in having to do an initdb, though it is an
> inconvenience; the difficulty is simply that any packaged distribution
> (rpm, deb, xxx) is going to have to replace all the old binaries. So by
> the time the package is ready to do the database upgrade, it has
> destroyed the means of dumping the old data. Lamar and I have to jump
> through hoops to get round this -- small hoops with flaming rags round
> them!
IMHO, if rpm and apt can't run a pre-install script before deleting the
old binaries they are going to replace/upgrade then you should complain
to authors of rpm and apt.
It seems that they are doing things in wrong order.
The right order should of course be
1) run pre-upgrade (pg_dumpall >dumpfile)
2) upgrade
3) run post-upgrade (initdb; psql < dumpfile)
---------------
Hannu
