Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:Linux stores pid/uid together with the signal. pid doesn't matter and no sane programmer will look at the uid, so it seems to be possible.
His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
we could also check errno for SIGPIPE rather than calling sigpending.
He has a concern about an application that already blocked SIGPIPE and
has a pending SIGPIPE signal waiting already. One idea would be to
check for sigpending() before the send() and clear the signal only if
SIGPIPE wasn't pending before the call. I realize that if our send()
also generates a SIGPIPE it would remove the previous realtime signal
info but that seems a minor problem.
Supposing that we don't touch the signal handler at all, then it is possible that the application has set it to SIG_IGN, in which case a SIGPIPE would be discarded rather than going into the pending mask. So I think the logic has to be:
pthread_sigmask to block SIGPIPE and save existing signal mask
send();
if (errno == EPIPE) { if (sigpending indicates SIGPIPE pending) use sigwait to clear SIGPIPE; }
pthread_sigmask to restore prior signal mask
The only case that is problematic is where the application had already blocked SIGPIPE and there is a pending SIGPIPE signal when we are entered, *and* we get SIGPIPE ourselves.
If the C library does not support queued signals then our sigwait will clear both our own EPIPE and the pending signal. This is annoying but it doesn't seem fatal --- if the app is writing on a closed pipe then it'll probably try it again later and get the signal again.
If the C library does support queued signals then we will read the existing SIGPIPE condition and leave our own signal in the queue. This is no problem to the extent that one pending SIGPIPE looks just like another --- does anyone know of platforms where there is additional info carried by a SIGPIPE event?
Is that really worthwhile? There are half a dozend assumption about the C library and kernel internal efficiency of the signal handling functions in the proposal. Adding a PQinitLib function is obviously a larger change, but it solves the problem.This seems workable as long as we document the possible gotchas.
I'm aware of one minor gotcha: PQinSend() is not usable right now: it relies on the initialization of pq_thread_in_send, which is only created in the middle of the first connectDB(). That makes proper signal handling for the first connection impossible.
-- Manfred
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
