The "No error" message occurs because pqcomm.c assumes bind returns the
error code in "errno", but on Windows it gets returned by
"WSAGetLastError()". This bug probably exists in many places in the
code.
The actual error should have said:
LOG: could not bind IPv6 socket: The system detected an invalid pointer
address in attempting to use a pointer argument in a call.
It turns out the root of the bug is that our definition of "addrinfo"
and Windows definition of "addrinfo" are not the same.
Microsoft followed the IETF RFC 2553 paper and defined ai_canonname
before ai_addr,
While PostgreSQL picks up its address from the GNU GCC implementation
which incorrectly has them the other way around.
Because the pointers were defined in different orders, we got the wrong
one.
If you use the Microsoft header throughout (HAVE_STRUCT_ADDRINFO = 1),
You don't see this problem.
Now I just have to figure out a way to update the patch...
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Thursday, August 25, 2005 2:51 PM
> To: Petr Jelinek
> Cc: Andrew Dunstan; pgsql-patches@postgresql.org; dpage@vale-
> housing.co.uk; Bruce Momjian; Chuck McDevitt
> Subject: Re: [HACKERS] Proposed patch to getaddrinfo.c to support
>
> Petr Jelinek <pjmodos@seznam.cz> writes:
> > Andrew Dunstan wrote:
> >> So, not quite there yet.
>
> > [I did make check only in W2K because I don't have direct access to
XP
> > machine now]
> > No thats not windows error thats postgres error (look at pqcomm.c),
> > which means HAVE_IPV6 is not defined.
>
> Possibly, but that's apparently not the only problem. I'm looking at
> the first buildfarm result with this patch,
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-08-
> 25%2018:56:02
>
> The interesting part is the postmaster log at the bottom:
>
> LOG: could not bind IPv4 socket: No error
> HINT: Is another postmaster already running on port 55678? If not,
wait a
> few seconds and retry.
> WARNING: could not create listen socket for "localhost"
> FATAL: could not create any TCP/IP sockets
>
> Apparently, access to IPv4 sockets isn't working either (and the "No
> error" isn't very helpful; would seem we're not reading the right
> status value).
>
> regards, tom lane