Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

"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

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

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

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

"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

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

"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

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

"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

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

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

"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

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

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