Hi,
> Knowing that it is possible for WaitForMultipleObjectsEx to lock up means=
that it is not safe to call with an INFINITE timeout. =A0The workaround th=
at's being discussed is beginning to look like the one at line 172 of socke=
t.c. =A0It's bad enough that there is a WSASend in pgwin32_waitforsinglesoc=
ket(). =A0I doubt you also want to add a WSARecv. =A0There should be a clea=
ner way to handle both of these situations.
>
The change at line 318 in socket.c and using an infinite loop there as
proposed by Magnus, makes much more sense IMO.
> I am planning to eventually kill the stats collector and see if that clea=
rs up the hanging issue, but I want to keep the system state in place for a=
bit longer in case there is some other diagnostic steps I should try. =A0I=
've exhausted everything I could think of.
>
Yeah it will be interesting to see if the collector starts functioning
fine after the restart. That might hint that the kernel object
representing the socket is maybe fine but would not prove conclusively
that the issue is with PG code because the layer used by
WaitForMultipleObjectsEx might have issues too.
Regards,
Nikhils
--=20
http://www.enterprisedb.com
