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