Re: libpq and psql not on same page about SIGPIPE - Mailing list pgsql-hackers

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.

Right.

> 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

Yes, that is the logic in my patch, except that I don't check errno, I
just call sigpending(). There are a few writes and it seemed impossible
to check them all.  Also, we might get a SIGPIPE but as you mentioned
the SIGPIPE may have been ignored.

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

Right.

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

Right.

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

Right.  We could add a sigpending() check and if set we just don't clear
the SIGPIPE signal, but this adds an additional function call into the
mix that seemed unnecessary, though I could be convinced otherwise.

> This seems workable as long as we document the possible gotchas.

My patch documents the limitation.  I finished reading the
Addison-Wesley "Programming with POSIX Threads" book and it has helped
me with this stuff.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073