Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA25397; Wed, 29 Jul 1998 11:02:29 -0400 (EDT) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA07457; Wed, 29 Jul 1998 11:02:26 -0400 (EDT) To: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: [HACKERS] Coping with backend crash in libpq In-reply-to: Your message of Tue, 28 Jul 1998 22:16:02 -0700 (PDT) <9807290516.AA02881@hawk.illustra.com> Date: Wed, 29 Jul 1998 11:02:26 -0400 Message-ID: <7455.901724546@sss.pgh.pa.us> From: Tom Lane >> I say, install the signal handler for SIGPIPE on connection startup, but >> when you install it, it returns the previous defined action. If we find >> there was a previous defined action, we can re-install theirs, and let >> it handle the sigpipe. If an application later defines it's own >> sigpipe, over-riding ours, then they get no error message. This makes our correct functioning dependent on the application's SIGPIPE handler, which doesn't strike me as a good solution. Another problem is that if we leave a SIGPIPE handler in place, it will get called for SIGPIPEs on *other* pipes that the surrounding application may have open, and we have no way to know what the right response is. (AFAIK a SIGPIPE handler can't even portably tell which connection has SIGPIPEd.) >> Can we send a signal to the process, telling >> it the backend has exited. No. The client isn't necessarily even on the same machine as the postmaster/backend. Even if it were, I don't think we can take over a signal code that the frontend application might be using for something else. > Hmmm, perhaps fix psql so that it uses SIGPIPE more sensibly. SIGPIPE really > is the right signal to catch here. Well, psql is also using SIGPIPE sensibly: it's trying to prevent a hangup when sending data down a pipe to a subprocess that might terminate early. The real problem here is that SIGPIPE is designed wrong. It ought to be possible to enable/disable SIGPIPE on a per- file-handle basis ... but AFAIK that's not possible, and it's certainly not portable even if some Unixes support it. I'm still in favor of the check-for-input-just-before-send solution. That does leave a small window where we can fail, but really the failure should be pretty improbable: you have to assume that some other backend coredumps while yours is idle, and in a window of microseconds right before you are going to send a new command to your backend. I think the mess-with-catching-SIGPIPE approach is actually more likely to have problems in practice. It could interfere with normal functioning of the frontend app, whereas any possible failure of the other way requires a previous failure in some backend. Production backends shouldn't coredump too darn often, one hopes. regards, tom lane