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

Peter Eisentraut wrote:

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

My patch doesn't affect signal handling, my patch affects the response 
of connect() after it is interrupted by a signal.

>>Since we deal happily with EINTR for most of the frontend socket calls,
>>I don't see a reason not to cope with it for connect() too.  I am
>>somewhat concerned about what exactly it means for a non-blocking
>>connect, however.  Maybe it doesn't mean anything, and we could treat
>>it the same as EINPROGRESS.
>>
>
>I feel that if the user installed his signal handlers to interrupt system
>calls then he probably had a reason for it, possibly because of the timing
>aspects of his application.  Thus, it shouldn't be libpq's task to
>override that decision.  If the user doesn't want system calls to be
>interrupted, then he should install the signal handlers in the proper way.
>If he doesn't know how to do that, he needs to educate himself, that's
>all.
>

Let me ask you how you would handle SIGALRM without interrupting 
syscalls?  Further, how would you guarantee your SIGALRM handler would 
execute within your granular limits?

Yes, the user has a timing aspect.  Libpq isn't overriding it and my 
patch doesn't change that.  My patch adds the EINTR handling.  Currently 
there is no way for libpq to continue processing a connect call if that 
syscall is interrupted and the user is using POSIX defaults.  Please 
refer to the POSIX specification, I povided a quote in a previous message.

POSIX default signal handling sets SA_RESTART which -disables- system 
call restart.

At present, the PQconnect* function treats EINTR as a fatal error.

David