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: