>From da5cfb7d237a4a07b146fb9d255f0de72207de10 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Mon, 17 Jun 2013 16:00:58 +0200 Subject: [PATCH] libpq: Handle connect(2) returning EAGAIN/EWOULDBLOCK correctly libpq used to accept EWOULDBLOCK - which is allowed to have the same value as EAGAIN by posix - as a valid return code to connect(2) indicating that a connection is in progress. While posix doesn't specify either as a valid return code, BSD based systems and linux use it to indicate temporary resource exhaustion. Accepting either as a in-progress connection attempt leads to hard to diagnose errors when sending the startup packet: could not send data to server: Transport endpoint is not connected could not send startup packet: Transport endpoint is not connected Treating it as an error results in: could not connect to server: Resource temporarily unavailable Is the server running locally and accepting connections on Unix domain socket "..."? which is more accurate. --- src/interfaces/libpq/fe-connect.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c index 0d729c8..c17c303 100644 --- a/src/interfaces/libpq/fe-connect.c +++ b/src/interfaces/libpq/fe-connect.c @@ -1780,7 +1780,6 @@ keep_going: /* We will come back to here until there is addr_cur->ai_addrlen) < 0) { if (SOCK_ERRNO == EINPROGRESS || - SOCK_ERRNO == EWOULDBLOCK || SOCK_ERRNO == EINTR || SOCK_ERRNO == 0) { -- 1.8.2.rc2.4.g7799588.dirty