agora inbox for postgres@postgres.berkeley.edu  

help / color / mirror / Atom feed

From: Paul M. Aoki <aoki@postgres.Berkeley.EDU>
To: Marc Teitelbaum <marc@vangogh.CS.Berkeley.EDU>
Cc: Vincent Schenkelaars <schenkel@cs.few.eur.nl>
Cc: postgres@postgres.Berkeley.EDU
Subject: Re: postgres 4.2 beta installation
Date: Tue, 12 Apr 94 12:38:20 -0700
Message-ID: <199404121938.MAA16705@faerie.CS.Berkeley.EDU> (raw)
In-Reply-To: <199404121859.LAA28905@vangogh.CS.Berkeley.EDU>

Marc Teitelbaum <marc@vangogh.CS.Berkeley.EDU> writes:
> 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.

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  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: aoki@postgres.Berkeley.EDU, marc@vangogh.CS.Berkeley.EDU, schenkel@cs.few.eur.nl
  Subject: Re: postgres 4.2 beta installation
  In-Reply-To: <199404121938.MAA16705@faerie.CS.Berkeley.EDU>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox