On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund <and...@anarazel.de> wrote:
> Hi Petr, > > On 2016-01-02 09:17:02 +0100, Petr Jelinek wrote: > > so the commit which triggers this issue is > > 387da18874afa17156ee3af63766f17efb53c4b9 , not sure why yet (wanted to > give > > heads up early since multiple people are looking at this). Note that the > > compilation around this commit is made harder by the fact that commit > > 91fa7b4719ac583420d9143132ba4ccddefbc5b2 breaks linking and fix is few > > commits later. > > Thanks for bisecting! What exactly did you use to reproduce? Shay's > npgsql binary? Or a plain psql session where you killed the client? > Given that Amit couldn't reproduce with the latter that seems an > interesting difference. > > I am also able to reproduce now. The reason was that I didn't have latest .Net framework and Visual Studio, which is must for the recent version of Npgsql. One probable reason of the problem seems to be that now for windows, we are emulating non-blocking behaviour by setting pgwin32_noblock = true which makes function pgwin32_recv() return EWOULDBLOCK and it would wait using WaitLatchOrSocket() instead of pgwin32_waitforsinglesocket(). There are some differences in the way both the API's (WaitLatchOrSocket() and pgwin32_waitforsinglesocket()) do wait, now may be that is the reason for this behaviour. One thing I have tried is that if I don't set pgwin32_noblock in secure_raw_read(), then this problem won't occur which lead to above reasoning. I am still investigating. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
