Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram
От | Nikhil Sontakke |
---|---|
Тема | Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram |
Дата | |
Msg-id | a301bfd90908052336w1423cbf4p56f05a9ec0c99cb@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram (Luke Koops <luke.koops@entrust.com>) |
Ответы |
Re: BUG #4958: Stats collector hung on
WaitForMultipleObjectsEx while attempting to recv a datagram
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: