Re: libpq and psql not on same page about SIGPIPE

Tom Lane wrote:

>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>  
>
>>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?
>
>  
>
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.

>This seems workable as long as we document the possible gotchas.
>
>  
>
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.
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