Bill Studenmund <wrstuden(at)zembu(dot)com> writes:
> 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?
Backends never fork more backends --- but there are some places that
launch transient children and wait for them to finish. A non-transient
subprocess should always be launched by the postmaster, never by a
> 2) Change to DFL around system() and then change back.
I think this is pretty ugly, and unnecessary.
> 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
That's the behavior that's in place now, but I do not like it. We
should not need to code an assumption that "this error isn't really
an error" --- especially when it only happens on some platforms.
On a non-Linux kernel, an ECHILD failure really would be a failure,
and the existing code would fail to detect that there was a problem.
Bottom line: I like solution #1. Does anyone have an objection to it?
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Vince Vielhaber||Date: 2001-07-30 23:16:01|
|Subject: developer's website|
|Previous:||From: Bill Studenmund||Date: 2001-07-30 23:09:03|
|Subject: Re: SIGCHLD handler in Postgres C function. |