From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Charles(dot)McDevitt(at)emc(dot)com |
Cc: | magnus(at)hagander(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: non-ipv6 vs hostnames |
Date: | 2011-08-17 18:28:33 |
Message-ID: | 1313605713.19987.8.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On ons, 2011-08-17 at 13:12 -0400, Charles(dot)McDevitt(at)emc(dot)com wrote:
> > On tis, 2011-08-16 at 16:17 +0200, Magnus Hagander wrote:
> > > Well, I got this on a win64 build. It's *supposed* to have ipv6. I
> > > wonder if it breaks on windows just because there is no ipv6 address
> > > on the machine...
> >
> > It would mean that getaddrinfo() of "::1" failed. That seems weird.
> >
>
> A system admin can set registry keys to disable IPv6, either partially (allowing ::1), or totally (all IPv6 addresses fail).
>
> If the system has IPv6 enabled, it's not possible for there to be no ipv6 address. There is always the link-local address of each LAN adapter.
The problem here is that the system cannot *parse* the address "::1".
This should not have anything to do with which addresses exist or could
exist.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-08-17 18:36:18 | Re: PATCH: Compiling PostgreSQL using ActiveState Python 3.2 |
Previous Message | Alvaro Herrera | 2011-08-17 17:52:00 | Re: Re: [COMMITTERS] pgsql: In pg_upgrade, avoid dumping orphaned temporary tables. This ma |