On Mon, 30 Jul 2001, Tom Lane wrote:
> Bill Studenmund <wrstuden(at)zembu(dot)com> writes:
> > Looking at source on the web, I found:
> > kernel/signal.c:1042
> > * Note the silly behaviour of SIGCHLD: SIG_IGN means that the
> > * signal isn't actually ignored, but does automatic child
> > * reaping, while SIG_DFL is explicitly said by POSIX to force
> > * the signal to be ignored.
> Hmm, interesting. If you'll recall, the start of this thread was a
> proposal to change our backends' handling of SIGCHLD from SIG_IGN to
> SIG_DFL (and get rid of explicit tests for ECHILD). I didn't quite see
> why changing the handler should make a difference, but above we seem to
> have the smoking gun.
> Which kernel, and which version, is the above quote from?
Linux kernel source, 2.4.3, I think i386 version (though it should be the
same for this bit, it's supposed to be MI). Check out
I do recall the reason for the thread. :-) I see three choices:
1) Change back to SIG_DFL for normal behavior. I think this will be fine
as we run w/o problem on systems that lack this behavior. If
turning off automatic child reaping would cause a problem, we'd
have seen it already on the OSs which don't automatically reap
children. Will a backend ever fork after it's started?
2) Change to DFL around system() and then change back.
3) Realize that ECHILD means that the child was auto-reaped (which is an
ok think and, I think, will only happen if the child exited w/o
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-07-30 23:14:22|
|Subject: Re: SIGCHLD handler in Postgres C function. |
|Previous:||From: Larry Rosenman||Date: 2001-07-30 23:04:53|
|Subject: Re: Re: OpenUnix 8 Patchj|