Skip site navigation (1) Skip section navigation (2)

Re: SIGCHLD handler in Postgres C function.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bill Studenmund <wrstuden(at)zembu(dot)com>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, spshealy(at)yahoo(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SIGCHLD handler in Postgres C function.
Date: 2001-07-30 23:14:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
backend, IMHO.

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

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 VielhaberDate: 2001-07-30 23:16:01
Subject: developer's website
Previous:From: Bill StudenmundDate: 2001-07-30 23:09:03
Subject: Re: SIGCHLD handler in Postgres C function.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group