Re: (A) native Windows port

On Tuesday 09 July 2002 01:46 pm, Hannu Krosing wrote:
> On Tue, 2002-07-09 at 18:30, Oliver Elphick wrote:
> > The main problem is getting access to the user data after an upgrade.

> Can't it be dumped in pre-upgrade script ?

The pre-upgrade script is run in an environment that isn't robust enough to
handle that. What if you run out of disk space during the dump? What if a
postmaster is running -- and many people stop their postmaster before
upgrading their version of PostgreSQL?

Besides, at least in the case of the RPM, during OS upgrade time the %pre
scriptlet (the one you allude to) isn't running in a system with all the
normal tools available. Nor is there a postmaster running. Due to a largish
RAMdisk, a postmaster running might cause all manners of problems.

And an error in the scriptlet could potentially cause the OS upgrade to abort
in midstream -- not a nice thing to do to users, having a package during
upgrade abort their OS upgrade when it is a little over half through, and in
an unbootable state.... No, any dumping of data cannot happen during the %pre
script -- too many issues there.

> 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.

Oh, so it's RPM's and APT's problem that we require so many resources during
upgrade.... :-)

> The right order should of course be

> 1) run pre-upgrade (pg_dumpall >dumpfile)
> 2) upgrade
> 3) run post-upgrade (initdb; psql < dumpfile)

All but the first step works fine. The first step is impossible in the
environment in which the %pre script runs.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11