Re: could not create IPv6 socket (AI_ADDRCONFIG) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: could not create IPv6 socket (AI_ADDRCONFIG)
Date
Msg-id 3176.1391497628@sss.pgh.pa.us
Whole thread Raw
In response to could not create IPv6 socket (AI_ADDRCONFIG)  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: could not create IPv6 socket (AI_ADDRCONFIG)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: could not create IPv6 socket (AI_ADDRCONFIG)  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@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



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Retain dynamic shared memory segments for postmaster lifetime
Next
From: Tom Lane
Date:
Subject: Re: narwhal and PGDLLIMPORT