Brent Verner <brent@rcfile.org> writes:
> | Unless someone can point out a situation where retrying connect()
> | after EINTR is actively bad, my inclination is to accept the patch.
> I've found numerous examples where connect() is retried after EINTR,
> infact it appears to be fairly common.
Perhaps it does work that way on your system, but that's not the point.
On a machine that behaves that way, we'll never see EINTR returned by
connect(), and so our reaction to it is unimportant. The question is
what we should do if we *do* get EINTR from connect(). AFAICS, the
appropriate response is to retry. We already do retry after EINTR in
libpq's recv, send, select, etc calls --- perhaps connect got overlooked
because it's usually only done at program startup.
After further thought, though, it's unclear to me why this solves
David's problem. If he's got a repeating SIGALRM on a cycle short
enough to interrupt a connect(), seems like it'd just fail again
on the next try.
regards, tom lane
