Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
