Re: [patch] helps fe-connect.c handle -EINTR more gracefully - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [patch] helps fe-connect.c handle -EINTR more gracefully
Date
Msg-id 29744.1004145109@sss.pgh.pa.us
Whole thread Raw
In response to Re: [patch] helps fe-connect.c handle -EINTR more gracefully  (David Ford <david@blue-labs.org>)
List pgsql-hackers
David Ford <david@blue-labs.org> writes:
> [ much ]

I think you are missing the point.  I am not saying that we shouldn't
deal with EINTR; rather I am raising what I think is a legitimate
question: *what* is the most appropriate response?  My reading of
HP's gloss suggests that we could treat EINTR the same as EINPROGRESS,
ie, consider the connect() to have succeeded and move on to the
wait-for-connection-complete-or-failure-using-select() phase.
If that works I would prefer it to repeating the connect() call,
primarily because it avoids any possibility of introducing an
infinite loop.

For PQrequestCancel we clearly do need to retry the connect(), since
that use of connect() isn't nonblocking.  But I'm not convinced that
we should do so in the main-line connection code.

> It is possible with the current code for the 
> connection to fail in non-blocking mode.  Reason: you call connect() in 
> non-blocking mode, break out of the section on EINPROGRESS, and continue 
> assuming that the connection will be successful.

No, we don't.  If you think that, then you haven't studied the code
sufficiently to be submitting patches for it.  What we actually do
is exactly what is recommended by the manpage you're quoting at me.
It's just split across multiple routines.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: 7.2b1 ...
Next
From: Bruce Momjian
Date:
Subject: Re: 7.2b1 ...