Peter Eisentraut <peter_e@gmx.net> writes:
> 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.
How are we "overriding" it? A more correct description would be that
we are "coping" with it. We already do so when a send or recv is
interrupted, so I don't see why there's a problem with extending that
policy to connect calls.
What I think you are arguing is that marking signal handlers SA_RESTART
is a sufficient answer for this issue, but I don't really agree, on
two grounds: (a) not everyone has POSIX signals, (b) SA_RESTART is a
blunt instrument because it's per-signal. A user might well want
SIGALRM to interrupt some operations, but that doesn't mean he wants it
to cause failures inside subroutine libraries. Look at the backend:
we make SIGALRM non-SA_RESTART, which means we need to retry after
EINTR in most places. We do it because we want certain specific waits
to be interruptible, not because we want a global policy of "fail if
interrupted". (Now that I look at it, I wonder whether SIGINT,
SIGTERM, SIGQUIT shouldn't be non-SA_RESTART as well, but that's a
different discussion.)
My quibble with David has been about whether the fix is correct in
detail, not about whether its purpose is correct.
regards, tom lane
