On Fri, 10 Oct 2003, Oliver Elphick wrote:
> Debian packages of PostgreSQL 7.4beta4 are available in the experimental
> section of the Debian archive.
One thing I've been thinking/worrying about recently is the upgrade
process. Rest assured this isn't rehashing the pg_upgrade debate though.
What I'm wondering about is that I'm faced with a production box that is
installed with a Redhat system, that's run by someone else and they do things
'by the book'. That is, software comes in RPM form, possibly RPMS form, but no
way does it come in any other form since it's obviously not supported in that
case. Now, we're coming up to the time when 7.4 is released, should I go to the
extent of porting the db from 7.3 I'll be faced with the situation where the
production db has to be brought down to do the upgrade which even after testing
may fail in the process. Factor into that that I'm sure the people admin-ing
the box probably will not do this during a quiet time, i.e. middle of the
night, I have a problem...unless the RPMs are relocatable.
I've not looked at many RPMs but I must say that the few I have have never been
relocatable. Can the postgresql RPMs not be made relocatable? At least in
that case I could run the two versions concurrently rather than the admins be
forced to shut 7.3 down, uninstall it, install 7.4, start it up and run the
upgrade/load scripts before reenabling the application.
If it were me I'd just use stow like I do on all my systems if only more
software wouldn't assume it knew where it was going to be installed before
configure and build, but that's a whole other gripe.
--
Nigel J. Andrews
