On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund <andres@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
