Re: Re: Sure enough, the lock file is gone - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Sure enough, the lock file is gone
Date
Msg-id 11319.980730032@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: Sure enough, the lock file is gone  (Lamar Owen <lamar.owen@wgcr.org>)
List pgsql-hackers
Lamar Owen <lamar.owen@wgcr.org> writes:
> Tom Lane wrote:
>> Lamar Owen <lamar.owen@wgcr.org> writes:
> How about an environment variable?  PGSOCKLOC?
>> It's spelled PGHOST as of 7.1 ...

> I'm talking about Unix domain socket location, not TCP/IP hostname,
> which PGHOST is, right?

No, in 7.1 PGHOST serves a dual purpose.  If a hostname beginning with
"/" is given, it's taken to specify Unix-socket communication using a
socketfile in the directory whose absolute path is PGHOST.  A tad crocky
but it avoided having to add an additional parameter to the PQconnect
family of functions ...

Also, on the postmaster side, there is a postmaster commandline
parameter to set the directory containing the socket files (and
lockfiles).  So it's possible for a given installation to configure
the socketfiles anywhere without modifying the binaries at all.
But you do need to set PGHOST on the client side to make this work.
It all comes back to what the default is.

Basically, what's bothering me is the idea that the RPM distribution
will have a different default socket location than the regular source
distribution.  I think that will cause a lot more problems than it
solves.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: Sure enough, the lock file is gone
Next
From: Tom Lane
Date:
Subject: Re: Re: Sure enough, the lock file is gone