i'm running multiple postgresql instances simultaneously on my server. that includes most recent releases from all major versions since 7.4 . (that means the latest 7.4.*, 8.0.*, 8.1.*, 8.2.*, 8.3.*) however the init scripts don't support custom port for each postgresql instance. i actually had to do a lot of initscript hacking on suse 10.2 on a different server. on gentoo it is much, much easier, since slotted postgresql packages appeared. this small hack allows each slotted postgresql-server to run on a different ports. changes are based on postgresql-8.3 init script. if variable PGPORT is specified in config file this port is used. if not, it defaults to standard 5432 port. ======================================================================= /etc/init.d/postgresql-8.3 (....) if [ "${PGPORT}" ] ; then PORT="PGPORT=${PGPORT}" else PORT=" " fi su -l ${PGUSER} \ -c "env PGDATA=\"${PGDATA}\" ${PORT} /usr/lib/postgresql-8.3/bin/pg_ctl start -w -o '--silent-mode=true ${PGOPTS}'" ======================================================================= the other problem: there is still an issue with command line tools, because there are symlinks in /usr/bin for only one postgresql installation that have to be switched with eselect postgresql (which actually doesn't seem to work for me, though). so, i made a bunch of symlinks to the tools somehow like this (again, 8.3.x example) for name in <postgres-8.3 directory>/bin/* do alias $(basename ${name})-83="PGPORT=5483 ${name}" done with those aliases/symlinks in place eselect postgresql could manage just the default symlinks (/usr/bin/psql , /usr/bin/pg_restore , etc). i've been running all this on suse-10.2 server for a couple months now (i had to hack the pid file name there as well, but afaics it's not needed on gentoo), so i can assume it was fairly well tested in that environment. server is used by a small team of people working with different databases on different postgresql versions. there are no issues with command line tools so far and all databases across different server versions seem to be working correctly. on gentoo i just tested whether i could run 8.2 and 8.3 together. seems like this short hack does the job. but it probably needs fixing up Reproducible: Always Steps to Reproduce: 1. install few slotted postgresql-servers 2. try to start at least two of them 3. watch them conflict over the same port Actual Results: ports should also be slotted, if needed. what's the point of having two different postgresql servers if you can run only one? Expected Results: user can easily configure slotted postgresql-server packages to use different ports and use them simultaneously. i'll provide necessary info, if needed.
This certainly looks useful for postgresql developers who are transitioning between versions (or have to support multiple simultaneously). Let's see what the postgresql team has to say about running simultaneously on different ports -- I wouldn't be surprised if some of them are doing it on their own boxes and might consider adding official support.
my first post might have been a bit confusing, so i'll just restate what i really mean ;-) the server port override is pretty much irrelevant, since you can do this in postgresql config and server will take it. i just put it in as an example. the actual point of this bug report is - to be able to conveniently run client tools from all installed postgresql slots simultaneously without the need to search for them in postgresql install dirs, or switching via eselect. currently i only have eselect wrapper symlink for one postgresql slot. that's sometimes not enough. i think eselect should handle the default set of symlinks , e.g. /usr/bin/psql, while there would be a set of addiotional symlinks - in case of psql command : /usr/bin/psql-{74,80,81,82,83} for each postgresql slot available.
Addressed in bug #311047
(In reply to comment #2) > my first post might have been a bit confusing, so i'll just restate what i > really mean ;-) > > the actual point of this bug report is > - to be able to conveniently run client tools from all installed postgresql > slots simultaneously without the need to search for them in postgresql install > dirs, or switching via eselect. > > currently i only have eselect wrapper symlink for one postgresql slot. that's > sometimes not enough. > > i think eselect should handle the default set of symlinks , e.g. /usr/bin/psql, > while there would be a set of addiotional symlinks - in case of psql command : > /usr/bin/psql-{74,80,81,82,83} for each postgresql slot available. > Upstream recommends using the latest client for connecting to any version of server; use the 8.4 client to connect to servers of version 8.4 and below. Is there a real problem that you're running into? By which I mean, other than your peculiar use case where you want to test each major version client.
well, the only point of this bug was to enable users to run all the available slotted postgresql utils without specifying full path, or dancing around with eselect. i don't think multiple postgresql installations on one machine are that rare. if 8.4 client works reliably with all slots from 7.4 upwards - i think it should be all right to close this bug.
I don't think it's rare, either, for multiple instances of PostgreSQL to be on the same machine. In fact, the recommended method of migrating databases calls for such a situation. That is why bug #311047 does address the PGPORT issue.
Committed
