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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

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

regards, tom lane