Re: pgstat: remove delayed destroy / pipe: socket error fix

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pgstat: remove delayed destroy / pipe: socket error fix
Date: 2006-04-06 17:43:17
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA0F8E0@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-patches by date

  From Date Subject
Next Message Kevin Grittner 2006-04-06 17:46:23 Re: pgstat: remove delayed destroy / pipe: socket
Previous Message Magnus Hagander 2006-04-06 17:26:02 Re: pgstat: remove delayed destroy / pipe: socket error fix