Re: could not create IPv6 socket (AI_ADDRCONFIG)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: could not create IPv6 socket (AI_ADDRCONFIG)
Date: 2014-02-04 07:07:08
Message-ID: 3176.1391497628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-02-04 07:10:47 Re: narwhal and PGDLLIMPORT
Previous Message Kyotaro HORIGUCHI 2014-02-04 06:55:09 Re: Retain dynamic shared memory segments for postmaster lifetime