> Cyril VELTER wrote:
> >
> >>> 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.
>
> Hmm. That really isn't supposed to happen, but seems it is. Does it work
> when you add that loop, though? Spits out the message and works, or does
> it spit out the message and still not work?
OK, I've the results of my tests :
With the previous code, then message "SOCKERROR" is printed 5 times
during the
whole process (100 Gb dump import with psql). There one group of three and one
group of two, but I don't have timestamps and am not sure if they are printing
in the same loop or not. The import is finally successful.
The second test I have done is to remove FD_ACCEPT I still have the
message
one times, but it still happen. The import is also sucessfull.
>
> I'm also a bit worried about it getting caught in a tight loop if the
> error codes are wrong, but probably it just goes back into waitfor.. and
> blocks the second time. Otherwise, you'd see screenfuls of that message.
>
> Can you determine if it was hit two times right after each other, or if
> there was time between them?
For the first test I don't known the amount of time between them (I
have two
groups separeted in the logs with other messages).
What do you think ? may be a bug in the windows server installation I
have
(this machines have not been updated for some times, perhaps I should try to do
that and see if the problem is still there. In the long run, I plan to upgrade
to windows 2003).
cyril
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
