Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 010017895AC for ; Tue, 7 Aug 2012 15:22:52 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SyoQb-0003dB-9m for pgsql-bugs@postgresql.org; Tue, 07 Aug 2012 18:22:51 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q77IMOf7001411; Tue, 7 Aug 2012 14:22:24 -0400 (EDT) From: Tom Lane To: Robert Haas cc: Luke Koops , pgsql-bugs@postgresql.org Subject: Re: BUG #4958: Stats collector hung on WaitForMultipleObjectsEx while attempting to recv a datagram In-reply-to: References: <200907311459.n6VExuSa036743@wwwmaster.postgresql.org> Comments: In-reply-to Robert Haas message dated "Tue, 07 Aug 2012 12:29:42 -0400" Date: Tue, 07 Aug 2012 14:22:23 -0400 Message-ID: <1410.1344363743@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/23 X-Sequence-Number: 33747 Robert Haas writes: > We just had a customer hit a very similar problem on 9.1.3, running on > Windows Server 2008 SP2. ... > The customer finds that they can reproduce this on a variety of > systems under heavy load. > Now, it looks to me like for this stack trace to happen, > PgstatCollectorMain() has got to call pgwin32_waitforsinglesocket (at > line 3002), and that function has to return true, so that got_data > gets set to true. Then PgstatCollectorMain() will call recv(), which > on Windows will really be pgwin32_recv, which will call > pgwin32_waitforsinglesocket, which must now hang. The fact that the > first pgwin32_waitforsinglesocket call returned true should mean that > the stats collector socket is ready for read, while the fact that the > second one did not return seems to imply that it's not ready for read, > close, or accept. So it almost looks like Windows can change its mind > about whether the socket is readable. > Or maybe we're telling it to change its mind. This sounds an awful > lot like something that could have been caused by the oversights fixed > in commit b85427f2276d02756b558c0024949305ea65aca5. Was there a > reason we didn't back-patch that? Sure: it was unproven that that fixed anything at all, much less that it was bug-free enough to be safe to backpatch. Neither of those things has changed since May. If you want you can try making up a 9.1 with those changes and giving it to this customer to see if it fixes their problems --- but without some field testing of the sort, I'm pretty hesitant to put it into back branches. regards, tom lane