Re: Running v8.1 amd v8.2 at the same time for a transition - Mailing list pgsql-general

On Wed, 2007-06-06 at 10:51 +0100, Richard Huxton wrote:
> Hannes Dorbath wrote:
> > Running 2 PG instances is a trivial thing to do. It requires a quick
> > look at the PostgreSQL documentation to find out that:
>
> > But instead people spend their time on going out and ask how to use some
> > poor wrappers, their distribution provides. Probably this has costed
> > them more time than a look in the PG documentation.
>
> I think the point of the Debian (and hence ubuntu) wrappers is to let
> the *packaging system* install and run two or more concurrent
> installations. Otherwise there's no way to upgrade from one edition of
> Debian to another and take your databases with you.

Indeed, there are major problems for the packaging system because of the
need to dump and reload the database on a major upgrade.  When I was
doing the Debian packaging, my original approach was to try to automate
that procedure so that it would happen seamlessly during the package
update.  This frequently failed.

1. The dump might fail because of some corruption.
2. There might be some incompatibility which stopped the dump uploading
to the new version.
3. The DBA might not wish to upgrade yet.
4. A big database might take a long time to transfer; then there might
be problems with disk space.
5. There might be multiple databases; only the one on the default port
would be dumped and reloaded.

If a new package became available, it would automatically be uploaded on
a general upgrade unless the sysadmin placed it on hold; but placing it
on hold meant that bug-fixing releases didn't get installed either.  So
you lost either way.

If you assume that there are a dedicated sysadmin and a DBA who
thoroughly understand everything that is going on and know all the
command-line tools (and probably run Gentoo or Slackware and build
everything themselves any way!) you can justify leaving it up to them to
choose the right command pathnames and the right port numbers and see to
it that their users know what to do.  However, the majority of users of
packaging systems aren't that capable.  That's why they are using the
packaging system in the first place.  (Or perhaps they want to have time
to get some paying work done!)

Since I wanted to make life easier for users -- and hence for myself as
maintainer as well -- I invented the scheme for installing different PG
versions in parallel on Debian.  Admittedly it adds some complication,
but it avoids unexpected upgrade problems and allows for proper testing
before an upgraded database is let loose on its end users.  The scheme
had to allow for having multiple versions of every executable installed
simultaneously and it had to provide a means for ordinary users to get
to the right database without having to work out what pathnames and port
numbers to use and as far as possible without changing the way they were
already working.

Martin Pitt took over my initial design and simplified it considerably
and has made the system work very well.

> Now, I find the Debian approach complicated and fiddly, but I suspect
> that's because what it's doing is complicated and fiddly.

In fact there is no actual difference for the end-user unless more than
one version is installed simultaneously (which will normally only happen
while upgrade testing is going on) or unless the system is hosting
multiple separate databases; in the latter case I imagine that most
users are either guided by scripts or confined by an application program
to a single database.

Any suggestions for improvement?
--
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
   Do you want to know God?   http://www.lfix.co.uk/knowing_god.html