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?
I'm also pretty suspicious of the SOCK_ERRNO == 0 case, now that I look
at it, especially in view of the lack of any attempt to set errno to 0
before the call. The Single Unix Spec is pretty clear that EINTR and
EINPROGRESS are the only legit cases, so unless Windows is doing its own
thing, we could probably get rid of that too.
regards, tom lane