Re: Redhat RPMs (Was: Debian experimental packages - Mailing list pgsql-general

On Fri, 2003-10-10 at 22:08, Nigel J. Andrews wrote:
> 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.

Well, I can't speak for the RPM builders, but I have been thinking about
this issue in respect of the debs.

I am not happy about the current situation for Debian upgrading, which
seems to be pretty fragile.  There are a fair number of bug reports from
people for whom the upgrade has barfed in some way or other.  The
situation for RPMs is even worse, since the installation scripts are far
more rigidly constrained than are the Debian installation scripts.  Of
course, that's why Lamar and I would be so happy to see a working
pg_upgrade tool.  But there's no prospect of that in even the medium
term, as far as I can see.

Your suggestion of parallel installations is the solution I have been
considering.  If the new package could be installed alongside the old,
there would be no need to upgrade the data during installation and no
danger of data loss.

Another reason for considering this is for the benefit of people who
want to run multiple versions.  Perhaps they have an application which
is live and they want to keep that going while they update its code for
use with the new PostgreSQL; it will be much easier for them if the two
versions can be installed side by side as packages.  Other users may
have multiple database users, who want to use different software
versions.

For that to work, however, we need a mechanism for assigning a port to
each package and database and for determining which version of the
client software each user will get.  So that means that in each package,
psql must be renamed psql-7.3, psql-7.4 and so on.  Then psql becomes a
soft link to the default psql version.  Debian's alternatives system
(update-alternatives(8)) provides a convenient mechanism for making
those soft links if there is a single systemwide default, but not if
there are different users who want different versions.  I don't know if
Red Hat has anything similar.

At the same time, I would like to make the packages cope with multiple
database structures, which are also needed by ISPs and others who need
to charge users for space used.

Assuming multiple versions installed simultaneously, with multiple
data/base structures

DB struct
owner          PGDATA               Version           PGPORT

fred         /var/lib/pg/fred       7.3               5433
george       /var/lib/pg/george     7.4               5434
harry        /var/lib/pg/harry      7.4               5435

then the packages need to provide the means for each user to get the
right PGPORT and the appropriate client software to access that port.

I haven't got any further than this, but I wonder if this is something
that would be useful to the whole project and not just to the
distributions.  Any comments?

--
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                             http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "He that covereth his sins shall not prosper; but whoso
      confesseth and forsaketh them shall have mercy."
                                         Proverbs 28:13