"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>>>> If you don't remember, there was a fflush() called in fe-misc.c,
>>>> exactly in pqPuts() function that receives EPIPE and it's currently
>>>> not ignored.
> Yes, I recall the "broken pipe" problem and thought that someone had
> fixed it (most platforms didn't seem to see the problem, but Linux did).
fe-connect.c is set up to ignore SIGPIPE while trying to shut down the
connection. (The 6.3.2 release is broken on non-POSIX-signal platforms,
because it resets SIGPIPE to SIG_DFL afterwards, which may well not be
what the application wanted. I've fixed that in the version that I plan
to submit soon.)
There is no equivalent code to ignore SIGPIPE during ordinary writes to
the backend. I'm hesitant to add it on the following grounds:
1. Speed: a write would need three kernel calls instead of one.
2. I'm suspicious of code that alters signal settings during normal
operation. Especially in a library that can't know what else is
going on in the application. Disabling the application's signal
handler, even for short intervals, is best avoided.
3. It's only an issue if the backend crashes, which shouldn't happen
anyway ... shouldn't happen anyway ... shouldn't ... ;-)
The real question is what scenario is causing SIGPIPE to be delivered
in the first place. A search of the pgsql-hackers archives for
"SIGPIPE" yields only a mention of seeing SIGPIPE some of the time
(not always) when trying to connect to a nonexistent database.
If that's what's being complained of here, I'll try to look into it.
regards, tom lane