From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Ford <david(at)blue-labs(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] helps fe-connect.c handle -EINTR more gracefully |
Date: | 2001-10-27 01:11:49 |
Message-ID: | 29744.1004145109@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Ford <david(at)blue-labs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-10-27 01:38:40 | Re: 7.2b1 ... |
Previous Message | Lamar Owen | 2001-10-27 01:04:54 | Re: 7.2b1 ... |