472,138 Members | 1,676 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,138 software developers and data experts.

Multiple database services and multiple versions on Red Hat Linuxsystems

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
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


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 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

Nov 12 '05 #1
0 1467

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Rory Becker | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.