Thread: Considerations for running current cvs pgsql and pgsql release on same machine?
Considerations for running current cvs pgsql and pgsql release on same machine?
From
"Robert B. Easter"
Date:
I'm wanting to run pgsql 7.0.3 release and pgsql current cvs on the same machine without them conflicting (if possible). Can someone explain what I should look out for when trying to do this? I assume I'll have to configure --with-pgport=5433 (something other than 5432). How will the use of the environment variables PGDATA and PGLIB be affected if I have them still pointing at the release version? I'm wanting to begin keeping an updated pgsql-cvs installation running and maybe get active in working on the sources. Maybe I can start out with documentation stuff. I've been following this list long enough and still enjoy it so I want to try towards contributing stuff. -- -------- Robert B. Easter reaster@comptechnews.com --------- - CompTechNews Message Board http://www.comptechnews.com/ - - CompTechServ Tech Services http://www.comptechserv.com/ - ---------- http://www.comptechnews.com/~reaster/ ------------
Re: Considerations for running current cvs pgsql and pgsql release on same machine?
From
Tom Lane
Date:
"Robert B. Easter" <reaster@comptechnews.com> writes: > I'm wanting to run pgsql 7.0.3 release and pgsql current cvs on the same > machine without them conflicting (if possible). Can someone explain what I > should look out for when trying to do this? I routinely run multiple versions at the same time. You need a separate port, install directory, and data directory for each. Easiest way to do this is to configure the non-default versions with ./configure --with-pgport=nnn --prefix=/path/to/someplace to establish their ports and install dirs, and then initdb each version with the appropriate data directory specified. A user then doesn't have to do much except make his PATH point at the PREFIX/bin dir for the version he wants to use at the moment. You may also find that you have to pump up your kernel's IPC resource parameters in order to start up multiple postmasters. > How will the use of the environment variables PGDATA and PGLIB be > affected if I have them still pointing at the release version? They had better have the right values while initdb'ing or starting each individual version. There's no good reason to have either one set in the general environment, or actually to set them at all --- you can get the same results with command line switches to initdb and postmaster, with much less chance of bad side-effects. A tip I find handy is to make sure that the databases available under each live postmaster have distinct names. This helps to avoid the mistake of testing against 7.0.2 when you thought you were testing against 7.0.3 or current or whatever... > I've been following this list long enough and still > enjoy it so I want to try towards contributing stuff. Welcome aboard! regards, tom lane
Re: Considerations for running current cvs pgsql and pgsql release on same machine?
From
"Robert B. Easter"
Date:
On Friday 22 December 2000 22:05, Tom Lane wrote: > I routinely run multiple versions at the same time. You need a separate > port, install directory, and data directory for each. Easiest way to do > this is to configure the non-default versions with > > ../configure --with-pgport=nnn --prefix=/path/to/someplace > > to establish their ports and install dirs, and then initdb each version > with the appropriate data directory specified. A user then doesn't have > to do much except make his PATH point at the PREFIX/bin dir for the > version he wants to use at the moment. > > You may also find that you have to pump up your kernel's IPC resource > parameters in order to start up multiple postmasters. > > > How will the use of the environment variables PGDATA and PGLIB be > > affected if I have them still pointing at the release version? > > They had better have the right values while initdb'ing or starting > each individual version. There's no good reason to have either one > set in the general environment, or actually to set them at all --- you > can get the same results with command line switches to initdb and > postmaster, with much less chance of bad side-effects. > > A tip I find handy is to make sure that the databases available under > each live postmaster have distinct names. This helps to avoid the > mistake of testing against 7.0.2 when you thought you were testing > against 7.0.3 or current or whatever... Thanks for these tips. I took out all global PG environment variables from /etc/profile. The way I did it, was to make a directory /etc/pgsql.d and in there have files pgsql.sh and pgcvs.sh for production and cvs test environments. Each sets up the variables: # Change these two PGHOME=/usr/local/pgsql or /home/pgcvs/pgsql PGPORT=5432 or 5433 PGLIB=$PGHOME/lib PGDATA=$PGHOME/data LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PGLIB MANPATH=$MANPATH:$PGHOME/man PATH=$PGHOME/bin export PGHOME PGPORT PGLIB PGDATA LD_LIBRARY_PATH MANPATH PATH These two files are then included into .profile in user directories like: # Pgsql prod .. /etc/pgsql.d/pgsql.sh or # Pgsql cvs dev .. /etc/pgsql.d/pgcvs.sh The cvs development version runs under user pgcvs while the production runs under user postgres as normal. The only little problem about this setup is that I can almost just run pgsql.sh and pgcvs.sh to switch between the two environments while logged in as a user. But if I do, PATH, MANPATH and LD_LIBRARY path, because they append, don't replace one thing for another. I'm sure that can be fixed with some simple bash/awk/sed trick but I haven't tried yet. The next thing is to setup another local-only httpd on port 8080 or whatever and get another php to compile with the cvs libs so I can test web stuff. -- -------- Robert B. Easter reaster@comptechnews.com --------- - CompTechNews Message Board http://www.comptechnews.com/ - - CompTechServ Tech Services http://www.comptechserv.com/ - ---------- http://www.comptechnews.com/~reaster/ ------------