Re: pgstat: remove delayed destroy / pipe: socket error fix - Mailing list pgsql-patches

From Magnus Hagander
Subject Re: pgstat: remove delayed destroy / pipe: socket error fix
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0F8E0@algol.sollentuna.se
Whole thread Raw
In response to pgstat: remove delayed destroy / pipe: socket error fix  ("Peter Brant" <Peter.Brant@wicourts.gov>)
List pgsql-patches
> Oh, and checking the code go pgwin32_recv, I think I see
> where this is coming from: pgwin32_recv calls
> pgwin32_waitforsinglesocket(). If that one succeeds *and a
> signal is delivered while it's waiting*, we'll get out og
> pgwin32_waitforsinglesocket() without clearing the WSA code.
> The rest of the pg code uses errno which is properly set to
> EINTR, but the pipe code uses WSAGetLastError() directly.
>
> The fix for that is probably to add a
> WSASetLastError(WSAEINTR)  right after the errno=EINTR in
> pgwin32_waitforsinglesocket().
>
> Does this seem right? Can you try by adding this, and then
> backing out your pgstats patch, and see if this alone is enough?

Nevermind, this is not going to work. Looking closer at the stats code,
it shows that the stats code will retry based on what's in errno, not
WSAGetLastError(). I still think we need to set the WSA error as well,
but that alone won't fix it.

The question still remains - how did we get  WSAEWOULDBLOCK. It must be
WSARecv returning WSAEWOULDBLOCK even if pgwin32_waitforsinglesocket()
says it's available to be read from.

Perhaps the loop needs to be in pgwin32_recv instead?

//Magnus

pgsql-patches by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: pgstat: remove delayed destroy / pipe: socket error fix
Next
From: "Kevin Grittner"
Date:
Subject: Re: pgstat: remove delayed destroy / pipe: socket