Ah-hah, I see it. pgwin32_select() uses WaitForMultipleObjectsEx() with an event for the socket read-ready plus an event for signal arrival. It returns EINTR if the return code from WaitForMultipleObjectsEx shows the signal-arrival event as fired. However, WaitForMultipleObjectsEx is defined to return the number of the *first* event in the list that is fired. This means that if the socket comes read-ready at the same time the SIGALRM arrives, pgwin32_select() will ignore the signal, and it'll be processed by the subsequent pgwin32_recv(). Now I don't know anything about the Windows scheduler, but I suppose it gives processes time quantums like everybody else does. So "at the same time" really means "within the same scheduler clock tick", which is not so unlikely after all. In short, before the just-committed patch, the Windows stats collector would fail if a stats message arrived during the same clock tick that its SIGALRM timeout expired. I think this explains not only the intermittent stats regression failures, but the reports we've heard from Merlin and others about the stats collector being unstable under load on Windows. The heavier the load of stats messages, the more likely one is to arrive during the tick when the timeout expires.
There's a second problem in pgwin32_waitforsinglesocket() that may be getting in your way.
Inside of pgwin32_waitforsingleselect(), we create a kernel synchronization object (an Event) and associate that Event with the socket. When the TCP/IP stack detects interesting traffic on the socket, it signals the Event object (interesting in this case is READ, WRITE, CLOSE, or ACCEPT, depending on the caller) and that wakes up the call to WaitForMultipleObjectsEx().
That all works fine, unless you have two or more sockets in the backend (the important part is that src/include/port/win32.h #define's select() and other socket-related function - if you compile a piece of network code that happens to #include port/win32.h, you'll get the pgwin32_xxx() versions).
The problem is that, each time you go through pgwin32_waitforsinglesocket(), you tie the *same* kernel object (waitevent is static) to each socket. If you have more than one socket, you'll tie each socket to the same kernel event. The kernel will signal that Event whenever interesting traffic appears on *any* of the sockets. The net effect is that, if you are waiting for activity on socket A, any activity on socket B will also awaken WaitForMultipleObjects(). If you then try to read from socket A, you'll get an "operation would block error" because nothing happened on socket A.
The fix is pretty simple - just call WSAEventSelect( s, waitevent, 0 ) after WaitForMultipleObjectsEx() returns. That disassociates the socket from the Event (it will get re-associated the next time pgwin32_waitforsingleselect() is called.
I ran into this problem working on the PL/pgSQL debugger and I haven't gotten around to posting a patch yet, sorry.
-- Korry ([EMAIL PROTECTED])
