Subject: Re: postgres 4.2 beta installation

From: Marc Teitelbaum <[email-masked]>
Date: Tue, 12 Apr 1994 11:59:57 -0700

Perhaps you _do_ have PGHOST or PGDATA set in your environment and it's
finding the wrong postmaster.  Use printenv(1) to see if it is.

---

From: [email-masked] (Paul M. Aoki)
Date: Tue, 12 Apr 94 12:38:20 -0700

> finding the wrong postmaster.  Use printenv(1) to see if it is.

a bit of clarification:

PGHOST and PGPORT only affect the operation of client programs, 
not the postmaster or the backend.  setting these incorrectly
will not cause the postmaster to dump core on startup.  (at 
least, it doesn't for me.)

PGDATA only affects the operation of the postmaster, not
client programs.
PGDATA only comes into play when the postmaster forks off
a backend.  you can actually start the postmaster with PGDATA
set to a non-existent directory and it won't complain -- its
child processes will complain.  setting this incorrectly will
will not cause the postmaster to dump core on startup.  (at 
least, it doesn't for me.)

none of these variable affects the postmaster's search path.
however, the path with which you invoke the postmaster and
your own $PATH do affect the postmaster's search path.  in
fact, this is the *only* thing that should be affected by
the pathname with which you start the postmaster, which is
why i suspect a $PATH problem or a problem with the contents
of the directories within $PATH.

the original problem statement didn't give a core stack dump
or a description of when it occurs (at startup or later).

once scenario i can see happening is:
- starting postmaster using $PATH starts up a 4.1 postmaster
- 4.2 client attempts to connect, causing 4.1 postmaster to die
another is:
- bin directories and/or $PATH are scrambled, causing postmaster
and postgres to be incompatible

it's impossible to say.

i will say that the other person's problems (the person who
was getting 4.1 backends) were solved by:
	- doing chmod 000 on the root of the postgres 4.1 tree
	- cleaning up shell environment
	- reinstalling 4.2
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki