Re: [HACKERS] libpq and psql not on same page about SIGPIPE

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, patch applied.  I also documented an optimmization we might make
> > leter in fe-secure.c:
>
> >         n = send(conn->sock, ptr, len, 0);
> >         /*
> >          *  Possible optimization:  if sigpending() turns out to be an
> >          *  expensive operation, we can set sigpipe_pending = 'true'
> >          *  here if errno != EPIPE, avoiding a sigpending call.
> >          */
>
> I went ahead and did that (or a cleaner equivalent) because I think it's
> important that we not risk clearing events we shouldn't clear.  In the
> normal path where we don't get EPIPE, it's now certain that secure_write
> won't have any side effects on the application state; saving a kernel
> call is a free bonus.  The fe-print.c code is a bit more problematic
> but I tend to think it's vestigial anyway.

Agreed.

> Per our phone discussion this morning, this code should be solid except
> in the case where the C library is able to queue multiple pending
> SIGPIPE events.  Like you, I'm dubious that that exists in the real
> world, or that anybody could cope with it if it did.  (Example: if
> someone blocks SIGPIPE and calls a complex function like fprintf(), how
> could he be certain that only one SIGPIPE event had been queued before
> it returned?)

Great.  Right now the code path is only two pthread_sigmask() calls.
That has got to be quite fast, I bet.

--
  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, Pennsylvania 19073