| 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: | Whole Thread | Raw Message | 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!!! |