Re: [HACKERS] could not create IPv6 socket (AI_ADDRCONFIG)
Tom Lane wrote: Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: Hello, I have often seen inquiries about an log message from PostgreSQL server. LOG: could not create IPv6 socket: Address family not supported by protocol That's merely a harmless log message. If we're concerned about users worrying about log messages from this, I'd rather see us downgrade those log messages to DEBUG level than risk breaking the code with behaviors that were proven to be a bad idea a decade ago. But TBH I see no strong need to do anything here. How about just adding a HINT? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not create IPv6 socket (AI_ADDRCONFIG)
Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: Hello, I have often seen inquiries about an log message from PostgreSQL server. LOG: could not create IPv6 socket: Address family not supported by protocol That's merely a harmless log message. How about just adding a HINT? Hmm ... maybe, but how would you phrase the hint exactly? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not create IPv6 socket (AI_ADDRCONFIG)
Hello, At Tue, 04 Feb 2014 02:07:08 -0500, Tom Lane t...@sss.pgh.pa.us wrote in 3176.1391497...@sss.pgh.pa.us One good reason not to trust this too much is that getaddrinfo() is fundamentally a userspace DNS access function, and as such it has no very good way to know if there's currently an IPv4 or IPv6 interface configured on the local system. At minimum there are obvious race conditions in that. A case which would be more common is ::1 in /etc/hosts. I had following error with this patch for such a case. | LOG: could not bind IPv4 socket: Address already in use | HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. getaddrinfo returned two same entries having the same address AF_INET 127.0.0.1:14357. One of them is for ::1 in hosts. This is worse than current behavior X-( At Tue, 04 Feb 2014 10:31:03 -0500, Tom Lane t...@sss.pgh.pa.us wrote in 12552.1391527...@sss.pgh.pa.us Alvaro Herrera alvhe...@2ndquadrant.com writes: Tom Lane wrote: Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: LOG: could not create IPv6 socket: Address family not supported by protocol That's merely a harmless log message. How about just adding a HINT? Hmm ... maybe, but how would you phrase the hint exactly? Putting the 'exactly' aside, is it something means 'You will get this message when the feature to handle the address family is disabled', only for EAFNOSUPPORT ? Though I don't know whether such a hint is helpful for those who tend to mind that kind of message. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not create IPv6 socket (AI_ADDRCONFIG)
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: getaddrinfo returned two same entries having the same address AF_INET 127.0.0.1:14357. One of them is for ::1 in hosts. This is worse than current behavior X-( Yeah, the fundamental issue is that getaddrinfo tends to return bogus info. How about just adding a HINT? Hmm ... maybe, but how would you phrase the hint exactly? Putting the 'exactly' aside, is it something means 'You will get this message when the feature to handle the address family is disabled', only for EAFNOSUPPORT ? Though I don't know whether such a hint is helpful for those who tend to mind that kind of message. I still think the best thing might be to reduce the individual messages to DEBUG-something, and only produce a LOG entry if we are unable to bind to *any* of the addresses returned by getaddrinfo. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] could not create IPv6 socket (AI_ADDRCONFIG)
Hello, I have often seen inquiries about an log message from PostgreSQL server. LOG: could not create IPv6 socket: Address family not supported by protocol This is emitted on ipv6-disabled environment which was available for me by the following steps on CentOS 6.5, - Add 'NETWORKING_IPV6=no' into /etc/sysconfig/network - Create /etc/modprobe.d/disable-ipv6.conf with the following content. options net-pf-10 off install ipv6 /bin/true - Comment out the entry for ::1 in /etc/hosts - Reboot. - [Confirm that ip a and ifconfig -a don't show ipv6 addrs] The cause is that the server collects available listen addresses by getaddrinfo with hint.ai_flags not having AI_ADDRCONFIG set. pqcomm.c:299 in function StreamServerPort hint.ai_family = family; ! hint.ai_flags = AI_PASSIVE; hint.ai_socktype = SOCK_STREAM; The man page of getaddrinfo says that AI_ADDRCONFIG would help and I saw it actually did. Well, I excavated some discussions about this option from ancient pgsql-hackers, a decade ago. http://www.postgresql.org/message-id/20030703204355.ga12...@ping.be This looks a little broken behaviour to me. My guess is that it returns an AF_INET6 socket but doesn't support it in the kernel. In that case with the AI_ADDRCONFIG option it shouldn't have returned that address. The question is wether your getaddrinfo() supports that option, and wether it's working or not. I suppose AI_ADDRCONFIG is a quite obscure option at the time, but the time seems to have come when we can use this option. man getaddrinfo NOTES getaddrinfo() supports the address%scope-id notation for specifying the IPv6 scope-ID. AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED are available since glibc 2.3.3. AI_NUMERICSERV is available since glibc 2.3.4. RHEL/CentOS 4.9 and after seems satisfies the condition. I don't know about other platforms but it is enough to define it as 0 if not defined. In addition, it would not be a problem even if the option doesn't work as expected because the error handling code added at the time the above conversation took place would act as the last resort. There would be no way it can work destructively. Attached patch does this. Any suggestions ? regards, -- Kyotaro Horiguchi NTT Open Source Software Center diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c index 2b24793..121f70b 100644 --- a/src/backend/libpq/pqcomm.c +++ b/src/backend/libpq/pqcomm.c @@ -297,7 +297,7 @@ StreamServerPort(int family, char *hostName, unsigned short portNumber, /* Initialize hint structure */ MemSet(hint, 0, sizeof(hint)); hint.ai_family = family; - hint.ai_flags = AI_PASSIVE; + hint.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; hint.ai_socktype = SOCK_STREAM; #ifdef HAVE_UNIX_SOCKETS diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c index 305d126..1dd7f2a 100644 --- a/src/backend/postmaster/pgstat.c +++ b/src/backend/postmaster/pgstat.c @@ -344,7 +344,7 @@ pgstat_init(void) /* * Create the UDP socket for sending and receiving statistic messages */ - hints.ai_flags = AI_PASSIVE; + hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; hints.ai_protocol = 0; diff --git a/src/include/getaddrinfo.h b/src/include/getaddrinfo.h index 6192d1f..685d922 100644 --- a/src/include/getaddrinfo.h +++ b/src/include/getaddrinfo.h @@ -64,6 +64,11 @@ #define AI_PASSIVE 0x0001 #endif +#ifndef AI_ADDRCONFIG +/* Works as NOP if AI_ADDRCONFIG is not defined */ +#define AI_ADDRCONFIG 0x +#endif + #ifndef AI_NUMERICHOST /* * some platforms don't support AI_NUMERICHOST; define as zero if using -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] could not create IPv6 socket (AI_ADDRCONFIG)
Kyotaro HORIGUCHI horiguchi.kyot...@lab.ntt.co.jp writes: Hello, I have often seen inquiries about an log message from PostgreSQL server. LOG: could not create IPv6 socket: Address family not supported by protocol That's merely a harmless log message. - hints.ai_flags = AI_PASSIVE; + hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; This, on the other hand, might actively break things. It did when we had it in before (cf the thread you link to and commit df63503dc). I don't have any faith that systems on which it is broken have vanished from the face of the earth. One good reason not to trust this too much is that getaddrinfo() is fundamentally a userspace DNS access function, and as such it has no very good way to know if there's currently an IPv4 or IPv6 interface configured on the local system. At minimum there are obvious race conditions in that. If we're concerned about users worrying about log messages from this, I'd rather see us downgrade those log messages to DEBUG level than risk breaking the code with behaviors that were proven to be a bad idea a decade ago. But TBH I see no strong need to do anything here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
