On 2013-06-26 12:07:54 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-06-17 16:16:22 +0200, Andres Freund wrote:
> >> Not accepting EWOULDBLOCK in the above if() results in:
> >> could not connect to server: Resource temporarily unavailable
> >> Is the server running locally and accepting
> >> connections on Unix domain socket "/tmp/.s.PGSQL.5440"?
> >> which makes more sense.
>
> > Could I convince a committer to NACK or commit & backpatch that patch?
>
> Some trawling in the commit history shows that the current logic dates
> from my commit 6d0d838cebdf2bcd5c03f5449a1888f1e120496f, which unified
> Windows and non-Windows code paths; the check for EWOULDBLOCK was added
> in the earlier commit ca5a51627919c6fb6ab5e23739615a674caa4037 which
> (claimed to) add support for non-blocking connect on Windows. So I'm
> concerned that your patch could break that platform.
> A possible compromise is
>
> {
> if (SOCK_ERRNO == EINPROGRESS ||
> +#ifndef WIN32
> SOCK_ERRNO == EWOULDBLOCK ||
> +#endif
> SOCK_ERRNO == EINTR ||
> SOCK_ERRNO == 0)
>
> but I wonder whether it's safe to remove the case altogether. Could
> anyone research the situation for non-blocking connect() on Windows?
> Perhaps on Windows we shouldn't test for EINPROGRESS at all?
The way EWOULDBLOCK is mentioned on msdn
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms737625%28v=vs.85%29.aspx)
it indeed seems to be required.
I don't see how we could trigger the conditions for EINPROGRESS on
windows that msdn lists, but since we need it on unixoid systems and its
valid to treat the connect as partiall successfull on windows, there
seems little benefit in dropping it. So I guess the #ifdef you suggested
is the way to go.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
