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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq