Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::') - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')
Date
Msg-id 20151024031036.GB421105@tornado.leadboat.com
Whole thread Raw
In response to Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')  (Peter Eisentraut <peter_e@gmx.net>)
Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::')  (Tatsuo Ishii <ishii@postgresql.org>)
List pgsql-hackers
On Thu, Oct 22, 2015 at 07:59:27PM -0700, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > pg_ctl reads the address from postmaster.pid, which in turn derives from
> > listen_addresses:
> 
> > $ grep -E '(unix|listen)' postgresql.conf
> > listen_addresses = '0.0.0.0'
> > unix_socket_directories = ''
> 
> Hmm, now I see.  I was about to object that that's a pretty silly setting,
> but I see that we actually document it as supported.
> 
> > $ strace -e connect pg_ctl -D . -w start
> > --- SIGCHLD (Child exited) @ 0 (0) ---
> > waiting for server to start...connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No
suchfile or directory)
 
> > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> > connect(3, {sa_family=AF_INET, sin_port=htons(6432), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EINPROGRESS
(Operationnow in progress)
 
> > 403978 2015-10-23 00:45:06.677 GMT LOG:  redirecting log output to logging collector process
> > 403978 2015-10-23 00:45:06.677 GMT HINT:  Future log output will appear in directory "..".
> >  done
> > server started
> > Process 403975 detached
> 
> ... although this trace appears to show pg_ctl working just fine with this
> setting, which kinda weakens your theory.  Still, it wouldn't be the first
> thing we've seen fail on Windows but work elsewhere.

As I stated upthread, PQping("host='0.0.0.0'") is _not portable_.  It works on
GNU/Linux, which I used for that demo.  It fails on OpenBSD and Windows.

> I'd be inclined to suggest fixing it like this:
> 
>                         /* If postmaster is listening on "*", use localhost */
> -                       if (strcmp(host_str, "*") == 0)
> +                       if (strcmp(host_str, "*") == 0 ||
> +                           strcmp(host_str, "0.0.0.0") == 0 ||
> +                           strcmp(host_str, "::") == 0)
>                             strcpy(host_str, "localhost");
> 
> which covers the cases we document as supported.

On RHEL 5 and some other "active adult" systems, "localhost" does not reach a
listen_addresses='::' server.  IPv6 is available, but "localhost" resolves to
127.0.0.1 only.

The latest systems resolve "localhost" to both 127.0.0.1 and ::1, in which
case PQping("host='localhost'") will attempt both addresses in an unspecified
order.  Given a postmaster with listen_addresses='0.0.0.0', contacting ::1
first will fail (fine) or reach a different postmaster (not fine).

Kondo's design is correct.

> A different line of thought would be to teach the postmaster to record
> actually bound-to addresses in postgresql.conf, rather than regurgitating
> the listen_addresses setting verbatim.  That would likely be a lot harder
> (and less portable); though if we think there's anything besides pg_ctl
> looking at this field, it might be worth trying.

Binding to INADDR_ANY is not equivalent to binding to some list of concrete
addresses.

nm



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: JDBC driver debug out?
Next
From: Jeff Janes
Date:
Subject: Re: 9.5Beta1 psql wrapped format expanded output