> > Cyril VELTER wrote:
>
> >
> > > Searching the source files, it seems the error message is generated in
> > > port/win32/socket.c line 594.
> >
> > Right, but the important thing is which path down to that function is it
> > generated in. Which is why a backtrace would help.
>
> Yes, I understand that.
>
> >
> > Looking at the code, the problem is probably somewhere in
> > pgwin32_recv(). Now, it really shouldn't end up doing what you're
> > seeing, but obviously it is.
>
>
> After looking at the code of pgwin32_recv(), I don't understand why
> pgwin32_waitforsinglesocket() is called with the FD_ACCEPT argument.
>
> >
> > Perhaps we just need to have it retry if it gets the WSAEWOULDBLOCK?
> > Thoughts?
>
> I've modified pgwin32_recv() to do that (repeat the
> pgwin32_waitforsinglesocket() / WSARecv while the error is WSAEWOULDBLOCK and
> not raising this error. I've an upgrade running right now (I will have the
> result in the next hours).
Replying to myself, the upgrade is not finished yet, but I can confirm
that
there is cases where pgwin32_waitforsinglesocket() return and the WSARecv
immediatly fail. I-ve modified the end of pgwin32_recv() :
/* No error, zero bytes (win2000+) or error+WSAEWOULDBLOCK (<=nt4) */
for(;;) {
if (pgwin32_waitforsinglesocket(s, FD_READ | FD_CLOSE |
FD_ACCEPT,
INFINITE) == 0)
return -1;
r = WSARecv(s, &wbuf, 1, &b, &flags, NULL, NULL);
if (r == SOCKET_ERROR)
{
printf("SOCKERROR");
if (WSAGetLastError() != WSAEWOULDBLOCK)
{
TranslateSocketError();
return -1;
}
}
else
{
return b;
}
}
The printf("SOCKERROR") line have been hit two times.
Any though ?
Once this upgrade is finished, I will make another try removing
FD_ACCEPT from
the pgwin32_waitforsinglesocket() call.
cyril
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
