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

Tom Lane wrote:
> 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.

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