Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram

On Sat, Aug 1, 2009 at 01:49, Alvaro Herrera<alvherre(at)commandprompt(dot)com> wrote:
> Luke Koops wrote:
>
>> Description:        Stats collector hung on WaitForMultipleObjectsEx while
>> attempting to recv a datagram
>> Details:
>>
>> While running a load test with 80 processes connected to postgres, of which
>> 62 were generating load, the stats collector got blocked on
>> WaitForMultipleObjectsEx which was called with INFINITE timeout.  The stack
>> trace for the hung thread follows:
>
>
>> ntdll.dll!NtWaitForMultipleObjects+0xc
>> kernel32.dll!WaitForMultipleObjectsEx+0x11a
>> postgres.exe!pgwin32_waitforsinglesocket+0x1ed
>> postgres.exe!pgwin32_recv+0x90
>> postgres.exe!PgstatCollectorMain+0x17f
>> postgres.exe!SubPostmasterMain+0x33a
>> postgres.exe!main+0x168
>> postgres.exe!__tmainCRTStartup+0x10f
>> kernel32.dll!BaseProcessStart+0x23
>
> I have seen this problem too.  The process seems stuck for no good
> reason.  I wondered at the time if it could be a kernel issue.  I
> remember trying to send some data to the collector to verify whether
> it'd wake up, but no luck.  (I mean I couldn't find a way to do it on
> Windows).

I have seen this as well, but only in cases where there has been
broken firewall software or such things involved. I have seen a couple
of reports from the field though.

Anyway, this really is a should-never-happen thing. As soon as a new
packet is sent in, WaitForMultipleObjectsEx() should return right
away. And given that backends regularly send packets over, it
shouldn't be an issue even if we miss one...

To generate packets, you should be able to use for example "nc" that
is available as a win32 binary as well.

--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/