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: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
