On Sat, Aug 1, 2009 at 01:49, Alvaro Herrera<alvhe...@commandprompt.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/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
