Re: [HACKERS] Re: SIGPIPE gripe

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

golem$ psql nada
Connection to database 'nada' failed.
FATAL 1: Database nada does not exist in pg_database
golem$ psql nada
Broken pipe
golem$

This is on a Linux box with Postgres code frozen on 980408. I assume
that full v6.3.2 exhibits the same...

- Tom