From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brent Verner <brent(at)rcfile(dot)org> |
Cc: | David Ford <david(at)blue-labs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [patch] helps fe-connect.c handle -EINTR more gracefully |
Date: | 2001-10-26 14:22:16 |
Message-ID: | 23846.1004106136@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brent Verner <brent(at)rcfile(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-10-26 14:46:23 | Re: [patch] helps fe-connect.c handle -EINTR more gracefully |
Previous Message | tweekie | 2001-10-26 09:22:08 | Re: Is there no "DESCRIBE <TABLE>;" on PGSQL? help!!! |