Horton

Thread

  1. Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <lrosenman@pervasive.com> — 2006-03-28T22:07:54Z

    Greetings,
    After helping a user on irc, I was wondering if there would be any
objection
to my making a patch that would:

1) expose DEFAULT_PGSOCKET_DIR via a libpq call
2) add this information to the psql --version output (or some other
switch, I'm agnostic).

for those weird times when some distro changes it, and you then
overwrite parts of it, 
it would be useful for diagnostics.

Comments?

LER


-- 
Larry Rosenman		
Database Support Engineer

PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX  78727-6531 

Tel: 512.231.6173
Fax: 512.231.6597
Email: Larry.Rosenman@pervasive.com
Web: www.pervasive.com

  2. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-28T22:28:02Z

    "Larry Rosenman" <lrosenman@pervasive.com> writes:
> 1) expose DEFAULT_PGSOCKET_DIR via a libpq call
> 2) add this information to the psql --version output (or some other
> switch, I'm agnostic).

pg_config would seem to be the appropriate place, not libpq nor psql.

			regards, tom lane

  3. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Darcy Buskermolen <darcy@wavefire.com> — 2006-03-28T22:33:23Z

    On Tuesday 28 March 2006 14:07, Larry Rosenman wrote:
> Greetings,
>     After helping a user on irc, I was wondering if there would be any
> objection
> to my making a patch that would:
>
> 1) expose DEFAULT_PGSOCKET_DIR via a libpq call
> 2) add this information to the psql --version output (or some other
> switch, I'm agnostic).
>
> for those weird times when some distro changes it, and you then
> overwrite parts of it,
> it would be useful for diagnostics.

is it not shown by, (if it's not default of /tmp) ?
pg_config --configure

>
> Comments?
>
> LER

-- 
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

  4. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-28T22:36:05Z

    Tom Lane wrote:
> "Larry Rosenman" <lrosenman@pervasive.com> writes:
>> 1) expose DEFAULT_PGSOCKET_DIR via a libpq call
>> 2) add this information to the psql --version output (or some other
>> switch, I'm agnostic).
> 
> pg_config would seem to be the appropriate place, not libpq nor psql.

The issue is when you overwrite PIECES of an install, and their
inconsistent.  I want to
put it in libpq, since that is what makes the connection to the server. 

pg_config doesn't link to libpq at all.

The issue is what psql (and any libpq using program) is going to use to find
the UNIX socket. 

we have the unix_socket_directory GUC, but that doesn't show the
DEFAULT_PGSOCKET_DIR that libpq is using, 
and in fact there is no where that the server exposes it's default, either.
I'm wondering
if we should expose it's default in unix_socket_directory when the config
doesn't set it.

LER


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893

  5. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-28T22:37:41Z

    Darcy Buskermolen wrote:
> On Tuesday 28 March 2006 14:07, Larry Rosenman wrote:
>> Greetings,
>>     After helping a user on irc, I was wondering if there would be
>> any objection to my making a patch that would:
>> 
>> 1) expose DEFAULT_PGSOCKET_DIR via a libpq call
>> 2) add this information to the psql --version output (or some other
>> switch, I'm agnostic). 
>> 
>> for those weird times when some distro changes it, and you then
>> overwrite parts of it, it would be useful for diagnostics.
> 
> is it not shown by, (if it's not default of /tmp) ?
> pg_config --configure
>

see my reply to Tom, that I just posted.  This is for diagnostic use, when
there are partial overwrites, and/or pathing issues that are causing a
particular
libpq/psql combination to not necessarily agree on what's where.

I want to expose exactly what libpq is using.

LER
 
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893

  6. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-29T03:32:28Z

    "Larry Rosenman" <ler@lerctr.org> writes:
> Tom Lane wrote:
>> pg_config would seem to be the appropriate place, not libpq nor psql.

> The issue is what psql (and any libpq using program) is going to use to find
> the UNIX socket. 

No, the issue is where the server put the socket.  libpq is the wrong
place because libpq is not the only thing people use to connect to the
server.

If the DBA sets a non-default unix_socket_directory via postgresql.conf
then you're screwed no matter what: no client-side code can hope to tell
you where it is.  The only thing that is useful to inspect is the
server's compile-time default, and pg_config is the right mechanism
to inspect that with.

			regards, tom lane

  7. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-29T03:37:13Z

    Tom Lane wrote:
> "Larry Rosenman" <ler@lerctr.org> writes:
>> Tom Lane wrote:
>>> pg_config would seem to be the appropriate place, not libpq nor
>>> psql. 
> 
>> The issue is what psql (and any libpq using program) is going to use
>> to find the UNIX socket.
> 
> No, the issue is where the server put the socket.  libpq is the wrong
> place because libpq is not the only thing people use to connect to
> the server.  
> 
> If the DBA sets a non-default unix_socket_directory via
> postgresql.conf then you're screwed no matter what: no client-side
> code can hope to tell you where it is.  The only thing that is useful
> to inspect is the server's compile-time default, and pg_config is the
> right mechanism to inspect that with.    
> 
> 			regards, tom lane

The other issue is borked installs where the server and libpq disagree.
What I'm looking for
 is to expose what libpq has for it's default as well as what the server is
using.  There is currently
 no way to determine what libpq has for it's default.  What happened in the
irc case was a partial re-install
 with non-matching server and libpq.

LER


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US

  8. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-29T03:59:46Z

    "Larry Rosenman" <ler@lerctr.org> writes:
> The other issue is borked installs where the server and libpq disagree.
> What I'm looking for
>  is to expose what libpq has for it's default as well as what the server is
> using.  There is currently
>  no way to determine what libpq has for it's default.  What happened in the
> irc case was a partial re-install
>  with non-matching server and libpq.

[ shrug... ]  So?  There isn't going to be any way that
random-app-using-libpq is going to have a way to tell the user what the
underlying copy of libpq is using for this default --- adding a call for
that will be nothing more nor less than a waste of code space.  You'd be
best off running strings(1) over the libpq.so file when the question
comes up.

			regards, tom lane

  9. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-29T04:02:39Z

    Tom Lane wrote:
> "Larry Rosenman" <ler@lerctr.org> writes:
>> The other issue is borked installs where the server and libpq
>>  disagree. What I'm looking for is to expose what libpq has for it's
>> default as well as what the server is using.  There is currently  no
>> way to determine what libpq has for it's default.  What happened in
>> the irc case was a partial re-install  with non-matching server and
>> libpq. 
> 
> [ shrug... ]  So?  There isn't going to be any way that
> random-app-using-libpq is going to have a way to tell the user what
> the underlying copy of libpq is using for this default --- adding a
> call for that will be nothing more nor less than a waste of code
> space.  You'd be best off running strings(1) over the libpq.so file
> when the question comes up.    

That's making the assumption that you know which libpq.  I was hoping to
have a psql commandline
Switch to dump the info, but with your objection(s), I'll just crawl back
under my rock.

 
> 
> 			regards, tom lane



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US

  10. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-29T04:13:18Z

    "Larry Rosenman" <ler@lerctr.org> writes:
> That's making the assumption that you know which libpq.  I was hoping to
> have a psql commandline
> Switch to dump the info, but with your objection(s), I'll just crawl back
> under my rock.

It's not that I don't feel your pain ... but if you don't know what
version of libpq you're using, I don't see where you get to assume that
psql is invoking the same version as your app-that's-actually-broken.
Seems like there's not any substitute for some forensic effort here.

On the server side, recent discussions about getting pg_ctl to behave
sanely in the face of non-default configurations have been leading me to
think about a proposal like this:

	postmaster --show-value guc-variable-name other-switches

with the behavior of parsing the postgresql.conf file, interpreting the
other-switches (which might include -D or -c that'd affect the result)
and then printing the value of the guc-variable to stdout and exiting.
This would allow pg_ctl to deal with issues such as non-default
unix_socket_directory.  Doesn't fix your problem of client-side
configuration variation, but would do a bit for the server side.

			regards, tom lane

  11. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-29T04:18:53Z

    Tom Lane wrote:
> "Larry Rosenman" <ler@lerctr.org> writes:
>> That's making the assumption that you know which libpq.  I was hoping
>> to have a psql commandline Switch to dump the info, but with your
>> objection(s), I'll just crawl back under my rock.
> 
> It's not that I don't feel your pain ... but if you don't know what
> version of libpq you're using, I don't see where you get to assume
> that psql is invoking the same version as your
> app-that's-actually-broken. Seems like there's not any substitute for
> some forensic effort here.   

The particular case was psql not being able to connect to a running
postmaster on
 the unix socket, because of the mismatch. 

What's the harm of a (pseudo code):

 const char *PQgetunixsocketdir(void)
 {
    return(DEFAULT_PGSOCKET_DIR)
 }

In libpq, and a psql command line switch to call it. 

> 
> On the server side, recent discussions about getting pg_ctl to behave
> sanely in the face of non-default configurations have been leading me
> to think about a proposal like this:  
> 
> 	postmaster --show-value guc-variable-name other-switches
> 
> with the behavior of parsing the postgresql.conf file, interpreting
> the other-switches (which might include -D or -c that'd affect the
> result) and then printing the value of the guc-variable to stdout and
> exiting. This would allow pg_ctl to deal with issues such as
> non-default unix_socket_directory.  Doesn't fix your problem of
> client-side configuration variation, but would do a bit for the
> server side.    

This would help as well. 



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US

  12. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Jeremy Drake <pgsql@jdrake.com> — 2006-03-29T04:43:25Z

    On Tue, 28 Mar 2006, Tom Lane wrote:

> "Larry Rosenman" <ler@lerctr.org> writes:
> > The other issue is borked installs where the server and libpq disagree.
> > What I'm looking for
> >  is to expose what libpq has for it's default as well as what the server is
> > using.  There is currently
> >  no way to determine what libpq has for it's default.  What happened in the
> > irc case was a partial re-install
> >  with non-matching server and libpq.
>
> [ shrug... ]  So?  There isn't going to be any way that
> random-app-using-libpq is going to have a way to tell the user what the
> underlying copy of libpq is using for this default --- adding a call for
> that will be nothing more nor less than a waste of code space.  You'd be
> best off running strings(1) over the libpq.so file when the question
> comes up.

When I encounter such behavior, my tool of choice tends to be strace(1)
rather than strings(1).  That way, you know what exactly the thing it
wants that it is not finding is...


-- 
Nothing astonishes men so much as common sense and plain dealing.
		-- Ralph Waldo Emerson

  13. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Tom Lane <tgl@sss.pgh.pa.us> — 2006-03-29T04:47:15Z

    "Larry Rosenman" <ler@lerctr.org> writes:
> What's the harm of a (pseudo code):

>  const char *PQgetunixsocketdir(void)
>  {
>     return(DEFAULT_PGSOCKET_DIR)
>  }

> In libpq, and a psql command line switch to call it. 

By the time you get done adding the infrastructure and documentation for
those two layers of features, you're talking about many hundreds of
lines of stuff, not four.  There are also definitional issues (what does
this do on platforms without Unix sockets) and future proofing (will we
always have DEFAULT_PGSOCKET_DIR).  So "what's the harm" is not the
appropriate measure --- especially when this proposal clearly doesn't
help in a lot of the scenarios in which one might wish to know the
information.

			regards, tom lane

  14. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-29T04:47:32Z

    Jeremy Drake wrote:
> 
> When I encounter such behavior, my tool of choice tends to be
> strace(1) rather than strings(1).  That way, you know what exactly
> the thing it wants that it is not finding is...  
That assumes that the user has strace(1) installed.  Yes, I've run into
systems
 that don't have it, and have no idea where the RPM/etc is for it :(.

There is also the differences between Linux (strace), SVR4 (truss), *BSD
(ktrace),
 etc, whereas a commandline switch to psql and the one-line function I
proposed would
 be standard across at least all the unix-like systems (since I think that
the windows code 
 doesn't enable HAVE_UNIX_SOCKETS, and therefore even if the library returns
a string, it's 
 useless.

LER


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US

  15. Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

    Larry Rosenman <ler@lerctr.org> — 2006-03-29T04:52:08Z

    Tom Lane wrote:
> "Larry Rosenman" <ler@lerctr.org> writes:
>> What's the harm of a (pseudo code):
> 
>>  const char *PQgetunixsocketdir(void)
>>  {
>>     return(DEFAULT_PGSOCKET_DIR)
>>  }
> 
>> In libpq, and a psql command line switch to call it.
> 
> By the time you get done adding the infrastructure and documentation
> for those two layers of features, you're talking about many hundreds
> of lines of stuff, not four.  There are also definitional issues
> (what does this do on platforms without Unix sockets) and future
> proofing (will we always have DEFAULT_PGSOCKET_DIR).  So "what's the
> harm" is not the appropriate measure --- especially when this
> proposal clearly doesn't help in a lot of the scenarios in which one
> might wish to know the information.    

I know that it's not just the 4 line function, etc.  However, there is
currently
 no way to find out if that non-standard setting has been changed.  Is it
safe to assume
 that we will always have a "default" unix socket that we connect to if no
hostname is specified?

However, as I said a couple of messages back, this isn't gonna fly, based on
your objections,
 so I'm gonna drop it.
   
-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 512-248-2683                 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US