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: fn*****@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
