Possible psql bug

On Thu, 10 Jul 2003 12:35 pm, Christopher Kings-Lynne wrote:

When I run psql on freebsd/alpha with latest CVS and no postmaster running,
I get this:
bizarre socket name

Interesting... I'm running OSF on Alpha and I get the usual
"/tmp/.s.PGSQL.5432". Perhaps it's related to IPv6 socket changes? I'm pretty
sure we don't have IPv6 support, so it would make sense it doesn't show up
here if I guess right.

What's your `uname -a`? FreeBSD has had IPv6 support for a while, IIRC.

Regards, Philip.

Interesting... I'm running OSF on Alpha and I get the usual
"/tmp/.s.PGSQL.5432". Perhaps it's related to IPv6 socket changes? I'm

pretty

sure we don't have IPv6 support, so it would make sense it doesn't show up
here if I guess right.

What's your `uname -a`? FreeBSD has had IPv6 support for a while, IIRC.

FreeBSD alpha.cacheboy.net 4.7-STABLE FreeBSD 4.7-STABLE #0: Mon Feb 3
19:25:10 WST 2003
adrian@alpha.cacheboy.net:/home/obj/usr/src/sys/GENERIC alpha

I seem to have IPV6 running:

de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::200:f8ff:fe22:4ba6%de0 prefixlen 64 scopeid 0x1
ether 00:00:f8:22:4b:a6
media: Ethernet autoselect (10baseT/UTP)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500

Chris

On Thu, 10 Jul 2003 01:33 pm, Christopher Kings-Lynne wrote:

FreeBSD alpha.cacheboy.net 4.7-STABLE FreeBSD 4.7-STABLE #0: Mon Feb 3

Hmm... I have 7.4devel built on FreeBSD 4.8 Intel running ipv6 at home - I'll
try the same tonight. It might help determine if it's architecture or OS.

Regards, Philip.

On Thu, Jul 10, 2003 at 10:35:04AM +0800, Christopher Kings-Lynne wrote:

When I run psql on freebsd/alpha with latest CVS and no postmaster running,
I get this:

bash-2.03$ psql test
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "���������`"?

This is probably getnameinfo() not supporting AF_UNIX, which I
already was afraid of. And the return value of getnameinfo()
isn't checked either.

My suggestion was to make our own getnameinfo_unix() like we have
a getaddrinfo_unix() for exactly the same reason.

It should be rather easy to write since we already have a
getnameinfo() in it that supports it.

Kurt

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

When I run psql on freebsd/alpha with latest CVS and no postmaster running,
I get this:

bash-2.03$ psql test
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "���������`"?

What's with the bizarre socket name?

I suspect the recent IPv6 code changes have broken the SockAddr struct
definition for you, probably by making unportable assumptions about
field size or layout. Do you have time to look at it, or can you grant
access to your machine for someone else?

regards, tom lane

This mail didn't make it to the list, it seems.

Kurt

Kurt Roeckx <Q@ping.be> writes:

On Thu, Jul 10, 2003 at 10:35:04AM +0800, Christopher Kings-Lynne wrote:

bash-2.03$ psql test
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "���������`"?

This is probably getnameinfo() not supporting AF_UNIX, which I
already was afraid of. And the return value of getnameinfo()
isn't checked either.

You are right --- I have just checked this on Chris' system, and that's
exactly what happens.

My suggestion was to make our own getnameinfo_unix() like we have
a getaddrinfo_unix() for exactly the same reason.

Right, and a getnameinfo2() that wraps that in the same way getaddrinfo2()
does. Can you make this happen? I'm a bit swamped ...

regards, tom lane

On Wed, Jul 23, 2003 at 12:23:38PM -0400, Tom Lane wrote:

My suggestion was to make our own getnameinfo_unix() like we have
a getaddrinfo_unix() for exactly the same reason.

Right, and a getnameinfo2() that wraps that in the same way getaddrinfo2()
does. Can you make this happen? I'm a bit swamped ...

I really have no time left. Leaving on holidays on Friday and
still have lots of other things to do.

Kurt