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 '::')
Re: Re: [BUGS] BUG #13611: test_postmaster_connection failed (Windows, listen_addresses = '0.0.0.0' or '::') |
| 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: