Multiple database services and multiple versions on Red Hat Linux systems

The way it works is that we require a specific service script for each 
database service (that is listening on each port).  Each of these 
services has a init script in /etc/init.d and a corresponding 
configuration file in /etc/sysconfig.  We use the 'chkconfig' utility to 
decide if each of those services will be activated on boot or not (it 
manipulates links under the /etc/init.c for each SysV run level).

We currently support multiple versions running.  I have myself half a 
dozen database services on my system with versions that range from 7.1 
to 7.4.  As each configuration file for each service points to the 
location of the proper binaries we have no problems dealing with this.

For example:

# cat /etc/sysconfig/rhdb-production
PGDATA=/usr/local/pgsql73/data
PGDATA2=/var/lib/pgsql2
PGDATA3=/var/lib/pgsql3
PGDATA4=/var/lib/pgsql4
PGENGINE=/home/fnasser/INST/pgsql73/bin
PGPORT=5433
PGLOG=/var/log/rhdb/rhdb-production
PGINITOPTIONS="--lc-messages=pt_BR"


As you can see the PGENGINE points to a binary that I built myself.  It 
is unfortunate that I can only have one RPM installed at a time.

Oliver Elphick has suggested different package names for each version 
that has a different catalog number (i.e., we need a pg_dump + 
pg_restore and we can't use these version's postmaster to access other 
version's data areas).

If we configure each of these packages with a different base path which 
includes the version and install, of course, to these versioned 
directories, we will end up with a setup similar to what I have on my 
system with the bakends I've built myself.  It can be even a Java-like 
solution

/usr/pgsql/postgresql71
/usr/pgsql/postgresql72
/usr/pgsql/postgresql73
/usr/pgsql/postgresql74

or have then scattered if the LSB so requires (I believe it does not 
address this case though).


As the binaries have been configured with the versioned paths, all RPMs 
are normal (not relocatable) and the binaries will refer to the 
libraries and other files of the proper version.  So by setting one's 
path, the user can use the version she or he seems fit.

For Red Hat's users (and Debian's, I believe), the 'alternatives' 
utility can be used to direct links from /usr/bin and such to the chosen 
version files, so a default could be established and for such there 
would be no need to change the PATH variable.


Also, the multiple versioning can be kept only on the server side.  On 
the client side the latest version will suffice if it guarantees a 
(minimum) 2 version backwards compatibility (as we do with the JDBC driver).

Besides the client side backaward compatibility, what the core 
postgresql team could also do to support this would be to add version 
checks and issue warnings on mismatches (or errors if used against a 
version too old).  Also, make sure the path of the binary does imply in 
the location of the other files (i.e., the path from configure is always 
used, and not some hardcoded value).

As you see, these goals can be achieved without any changes in the 
postgresql community sources.

Regards to all,
Fernando
-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


Mon, 27 Oct 2003 15:59:36 -0500
Fernando Nasser <fnasser@redhat.com>
Multiple database services and multiple versions on Red Hat Linux
	systems