Re: [patch] helps fe-connect.c handle -EINTR more gracefully

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

In response to

Browse pgsql-hackers by date

  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!!!