Tom Lane writes:
> AFAICT the client-side libpq doesn't (and shouldn't) touch signal
> handling at all, except for a couple of places in the print routines
> that temporarily block SIGPIPE.
Which was my point.
> Since we deal happily with EINTR for most of the frontend socket calls,
> I don't s
David Ford <[EMAIL PROTECTED]> writes:
> I traced several calls and they run through a few functions which end
> up in pqFlush. These code paths haven't checked the socket to see if it
> is ready for RW operation yet. pqFlush calls send() [ignoring SSL].
Where? AFAICS (ignoring the USE_SSL
>
>
>
>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 t
Actually, now that I look at this another time, there's an interesting
question to ask: have you compiled with USE_SSL?
The USE_SSL case definitely is broken, since it invokes the connect()
in blocking mode, but fails to retry on EINTR, which it clearly should
do in that mode. (What's even worse
David Ford <[EMAIL PROTECTED]> 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
>
>
>
>No, it should *not* look like that. The fe-connect.c code is designed
>to move on as soon as it's convinced that the kernel has accepted the
>connection request. We use a non-blocking connect() call and later
>wait for connection complete by probing the select() status. Looping
>on the c
"The **SA_RESTART** flag is always set by the underlying system in
POSIX mode so that interrupted system calls will fail with return value
of -1 and the *EINTR* error in /errno/ instead of getting restarted."
libpq's pqsignal.c doesn't turn off SA_RESTART for SIGALRM. Further,
pqsignal.c on
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Libpq certainly does deal with system calls being interrupted: It does
> not allow them to be interrupted. Take a look into the file pqsignal.c to
> see why.
??? Are you momentarily confusing backend and frontend libpq?
AFAICT the client-side lib
David Ford <[EMAIL PROTECTED]> writes:
> Thus a simplified loop should look like this:
No, it should *not* look like that. The fe-connect.c code is designed
to move on as soon as it's convinced that the kernel has accepted the
connection request. We use a non-blocking connect() call and later
w
David Ford writes:
> Libpq doesn't deal with system calls being interrupted in the slightest.
> None of the read/write or socket calls handle any errors. Even benign
> returns i.e. EINTR are treated as fatal errors and returned. Not to
> malign, but there is no reason not to continue on and ha
>
>
>This does not actually *say* that the appropriate behavior after EINTR
>is to retry, but reading between the lines one might infer that it will
>work like the nonblocking case, wherein a retry of connect tries to link
>to the existing connection attempt, not start a new one.
>
>What's more im
>
>
>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.
>
Ok, a few things. The connect() call is just an interface to the
kerne
David Ford <[EMAIL PROTECTED]> writes:
> Please wait a day before applying the patch, I want to make it a bit
> more clean/readable and make sure I covered everything in fe-connect.c,
BTW, reading the HPUX man page for connect I find the following relevant
error codes:
[EALREADY]
Brent Verner <[EMAIL PROTECTED]> 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.
On 26 Oct 2001 at 00:05 (-0400), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > I'm not sure this is correct. I've tried to /make/ a SIGALRM cause
| > connect to errno==EINTR, but I can't cause this condition.
|
| It wouldn't surprise me in the least if this behavior is
| platfor
>
>
>
>It wouldn't surprise me in the least if this behavior is
>platform-dependent. It may well be that David's kernel will allow
>connect() to be interrupted by SIGALRM while yours won't. (Which
>reminds me that neither of you specified what platforms you were
>testing on. For shame.) Or may
Many signals may be the cause of -EINTR. It depends on what the signal
is as to how it's normally handled. sigalarm is the most common due to
it being a timer event.
Generate a timer that expires as fast as possible (not too fast to
prevent code execution), and you should see things left and
Brent Verner <[EMAIL PROTECTED]> writes:
> I'm not sure this is correct. I've tried to /make/ a SIGALRM cause
> connect to errno==EINTR, but I can't cause this condition.
It wouldn't surprise me in the least if this behavior is
platform-dependent. It may well be that David's kernel will allow
c
On 25 Oct 2001 at 17:08 (-0400), David Ford wrote:
| I'm fresh in the code, but this has solved my issues with PQconnect*
| failing when interrupted by signals. Some of it is sloppy and not to my
| liking yet, but I'm still digging through to see if anything else needs
| touched. Comments app
I'm fresh in the code, but this has solved my issues with PQconnect*
failing when interrupted by signals. Some of it is sloppy and not to my
liking yet, but I'm still digging through to see if anything else needs
touched. Comments appreciated.
Honestly, I'm a bit surprised that this issue ha
20 matches
Mail list logo
