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

Search Discussions

  • Tom Lane at Dec 23, 2000 at 3:05 am

    "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
  • Robert B. Easter at Dec 23, 2000 at 7:39 am

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedDec 23, '00 at 2:42a
activeDec 23, '00 at 7:39a
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Robert B. Easter: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase