Re: libpq and psql not on same page about SIGPIPE

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073