Actually, now that I look at this another time, there's an interesting
question to ask: have you compiled with USE_SSL?
The USE_SSL case definitely is broken, since it invokes the connect()
in blocking mode, but fails to retry on EINTR, which it clearly should
do in that mode. (What's even worse is that you cannot suppress
the problem by setting allow_ssl_try false. If you compiled with SSL
support enabled then you lose anyway.)
I think we can fix this by moving the SSL startup code to a saner place,
namely in PQconnectPoll just before it's about to send the startup
packet. There's no reason why we shouldn't *always* do the connect()
in nonblock mode. We could switch the socket back to blocking mode
while invoking the SSL negotiation phase (which'd be skipped if not
allow_ssl_try, so that a library compiled with USE_SSL isn't ipso
facto broken for people who want non-SSL nonblocking connect).
If you are testing with USE_SSL then that explains why you are seeing
EINTR failures. If not, then we still have to ask whether EINTR really
needs to be handled differently from EINPROGRESS.
regards, tom lane