Thread: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?
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
"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 foris to expose what libpq has for it's default as well as what the server is using. There is currentlyno way to determine what libpq has for it's default. What happened in the irc case was a partial re-installwith 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 onthe 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
"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 systemsthat 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 wouldbe 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
currentlyno way to find out if that non-standard setting has been changed. Is it
safe to assumethat 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
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