Skip site navigation (1) Skip section navigation (2)

Re: Re: Sure enough, the lock file is gone

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Sure enough, the lock file is gone
Date: 2001-01-29 07:08:01
Message-ID: 3A7516D1.C5D53E8A@wgcr.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > But my issue is that libpq or any other client should be smart enough to
> > not have to assume the location.
> Er, how do you propose to do that?  The client cannot learn the correct
> location from the postmaster --- it must figure out *on its own* where
> the socket file is.  AFAICS you can't avoid having hardwired knowledge
> about how to do that in the client.

How does netstat find out?  A simple 
netstat -a --unix|grep \.s\.PGSQL
will get the full list of all postmaster sockets.  A little 'cut' or
'awk' work is simple enough.

I realize, of course, that netstat (and the underlying, on Linux,
/proc/net/unix file) is not portable. On Linux, simply grep
/proc/net/unix for the .s.PGSQL pattern and get the last column (or the
column before that, with the inode information).

Is there a portable way of listing the open unix domain sockets in this
manner, then deducing from the socket path what you need to know?

> You or somebody else previously suggested hardwiring the location of
> a configuration file, rather than the socketfile itself, but I can't
> see that that really improves matters in this context.  In particular,
> changing to such a method would still break backwards compatibility.

Not me.  The less hardwiring, the better, IMHO. And I'm glad you pointed
me to the new (undocumented that I could find) usage of PGHOST.  A
dynamic socket finder (assuming no specific socket path has been passed)
would not break backwards compatibility, as it would find the default
/tmp case.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-01-29 07:34:29
Subject: Re: Re: Sure enough, the lock file is gone
Previous:From: Oliver ElphickDate: 2001-01-29 06:53:07
Subject: Can PyGreSQL be updated?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group