Return-Path: owner-postman Delivery-Date: Tue, 12 Apr 94 15:45:32 -0700 Return-Path: owner-postman Received: from localhost (localhost [127.0.0.1]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with SMTP id MAA09782 for postgres-redist; Tue, 12 Apr 1994 12:38:25 -0700 Resent-From: POSTGRES mailing list Resent-Message-Id: <199404121938.MAA09782@nobozo.CS.Berkeley.EDU> Sender: owner-postman@postgres.Berkeley.EDU X-Return-Path: owner-postman Received: from faerie.CS.Berkeley.EDU (faerie.CS.Berkeley.EDU [128.32.149.14]) by nobozo.CS.Berkeley.EDU (8.6.4/8.6.3) with ESMTP id MAA09773 for ; Tue, 12 Apr 1994 12:38:24 -0700 Received: from localhost (localhost [127.0.0.1]) by faerie.CS.Berkeley.EDU (8.6.4/8.1B) with SMTP id MAA16705; Tue, 12 Apr 1994 12:38:20 -0700 Message-Id: <199404121938.MAA16705@faerie.CS.Berkeley.EDU> X-Authentication-Warning: faerie.CS.Berkeley.EDU: Host localhost didn't use HELO protocol From: aoki@postgres.Berkeley.EDU (Paul M. Aoki) To: Marc Teitelbaum Cc: Vincent Schenkelaars , postgres@postgres.Berkeley.EDU Subject: Re: postgres 4.2 beta installation Reply-To: aoki@postgres.Berkeley.EDU (Paul M. Aoki) In-reply-to: Your message of Tue, 12 Apr 1994 11:59:57 -0700 <199404121859.LAA28905@vangogh.CS.Berkeley.EDU> Date: Tue, 12 Apr 94 12:38:20 -0700 X-Sender: aoki@postgres.Berkeley.EDU Resent-To: postgres-redist@postgres.Berkeley.EDU X-Mts: smtp Resent-Date: Tue, 12 Apr 94 12:38:25 -0700 Resent-XMts: smtp Marc Teitelbaum 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