Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 1C0766328EA for ; Thu, 6 Aug 2009 03:36:39 -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 69734-09 for ; Thu, 6 Aug 2009 06:36:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by mail.postgresql.org (Postfix) with SMTP id 190856327DA for ; Thu, 6 Aug 2009 03:36:27 -0300 (ADT) Received: from source ([74.125.92.24]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSnp56s2kMwpqm4i39tOWw2hJKkRVhGCP@postini.com; Wed, 05 Aug 2009 23:36:28 PDT Received: by qw-out-2122.google.com with SMTP id 3so256967qwe.25 for ; Wed, 05 Aug 2009 23:36:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.46.18 with SMTP id h18mr7946022qaf.144.1249540585379; Wed, 05 Aug 2009 23:36:25 -0700 (PDT) In-Reply-To: References: <200907311459.n6VExuSa036743@wwwmaster.postgresql.org> <9837222c0908010828x7182494av3fd5909b64f4b2ad@mail.gmail.com> <9837222c0908030656m6ed69a26gc90a6c94b41a4c47@mail.gmail.com> <9837222c0908030716r416d789ewef3f77c65b39d916@mail.gmail.com> <9837222c0908030730kd59b9c2v7583666c5716aead@mail.gmail.com> Date: Thu, 6 Aug 2009 12:06:25 +0530 Message-ID: Subject: Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram From: Nikhil Sontakke To: Luke Koops Cc: Magnus Hagander , Alvaro Herrera , "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.197 tagged_above=-10 required=5 tests=AWL=1.403, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200908/26 X-Sequence-Number: 23853 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