Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 4D5606339AC for ; Mon, 3 Aug 2009 10:56:48 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 11158-02 for ; Mon, 3 Aug 2009 13:56:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mail.postgresql.org (Postfix) with ESMTP id 6027D634384 for ; Mon, 3 Aug 2009 10:56:37 -0300 (ADT) Received: by fxm6 with SMTP id 6so1480876fxm.19 for ; Mon, 03 Aug 2009 06:56:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.154.137 with SMTP id e9mr628818hbc.153.1249307795169; Mon, 03 Aug 2009 06:56:35 -0700 (PDT) In-Reply-To: References: <200907311459.n6VExuSa036743@wwwmaster.postgresql.org> <20090731234901.GD11098@alvh.no-ip.org> <9837222c0908010828x7182494av3fd5909b64f4b2ad@mail.gmail.com> Date: Mon, 3 Aug 2009 15:56:35 +0200 Message-ID: <9837222c0908030656m6ed69a26gc90a6c94b41a4c47@mail.gmail.com> Subject: Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram From: Magnus Hagander To: Nikhil Sontakke Cc: Alvaro Herrera , Luke Koops , pgsql-bugs@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.333 tagged_above=-10 required=5 tests=AWL=1.266, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200908/5 X-Sequence-Number: 23832 On Mon, Aug 3, 2009 at 15:47, Nikhil Sontakke wrote: > Hi, > >>> >>> >>>> 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. =A0The process seems stuck for no good >>> reason. =A0I wondered at the time if it could be a kernel issue. =A0I >>> remember trying to send some data to the collector to verify whether >>> it'd wake up, but no luck. =A0(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... >> > > And this fact should lend credence to Alvaro's (as well as mine) > suspicions that it seems to be a Windows kernel issue. > > As a consequence, Magnus I was wondering if having a loop similar to > the WRITE handling of waiting for a fixed timeout in a loop (rather > than an INFINITE call to WaitForMultipleObjectsEx) inside the > pgwin32_waitforsinglesocket() function will help for the READ case > too? I believe Teogor Sigaev had raised a similar concern a while back > about it: > > http://www.nabble.com/-GENERAL--Stats-collector-frozen--td8569977i20.html Maybe. I'm unsure if it's enough to just try another WaitForSingleObjectEx() on it, or if we need to actually issue a WSARecv() on it as well. Maybe it would be enough to just change the INIFINTE on line 318 of socket.c to a fixed value. That will loop down to WSARecv() which should exit with WSAEWOULDBLOCK which will cause us to do a short sleep and come back. But we'd have to change the limit of 5 somehow then, since in theory we should wait forever. Maybe that outer loop should just be a for(;;), what do you think?