Re: Some 9.5beta2 backend processes not terminating properly?

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