On 2016-01-02 12:05, Amit Kapila wrote:
> On Sat, Jan 2, 2016 at 3:16 PM, Andres Freund <andres@anarazel.de
> <mailto: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
> reasoning. I am still investigating.
>
Well, without pgwin32_noblock = true we never enter the code block which
calls WaitLatchOrSocket and hangs as in my testing this was always
called because of EWOULDBLOCK.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
