Is anyone working on this?
Tom Lane wrote:
> korry <[EMAIL PROTECTED]> writes:
> > The problem is that, each time you go through
> > pgwin32_waitforsinglesocket(), you tie the *same* kernel object
> > (waitevent is static) to each socket.
>
> > The fix is pretty simple - just call WSAEventS
Is anyone working on this?
---
Tom Lane wrote:
> korry <[EMAIL PROTECTED]> writes:
> > The problem is that, each time you go through
> > pgwin32_waitforsinglesocket(), you tie the *same* kernel object
> > (waitevent is stati
korry <[EMAIL PROTECTED]> writes:
> The problem is that, each time you go through
> pgwin32_waitforsinglesocket(), you tie the *same* kernel object
> (waitevent is static) to each socket.
> The fix is pretty simple - just call WSAEventSelect( s, waitevent, 0 )
> after WaitForMultipleObjectsEx() re
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
defin
I wrote:
> But ... AFAICS the only signal that could plausibly be arriving at the
> stats collector is SIGALRM from its own use of setitimer() to schedule
> stats file writes. So it seems that this failure occurs when the alarm
> fires between the select() and recv() calls; which is possible but i
The latest buildfarm report from trout,
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=trout&dt=2006-07-16%2014:36:19
shows a failure mode that we've seen recently on snake, but not for a
long time on any non-Windows machines: the stats test fails with
symptoms suggesting that the stats counters
