spshealy@yahoo.com writes:
> I have written a postgres C function that
> uses a popen linux system call. Orginally when I first tried it I kept
> getting an ECHILD. I read a little bit more on the pclose function
> and the wait system calls and discoverd that on LINUX if the signal
> handler for SIGCHLD is set to SIG_IGN you will get the ECHILD error
> on pclose(or wait4 for that matter). So I did some snooping around in
> the postgres backend code and found that in the traffic cop that the
> SIGCHLD signal handler is set to SIG_IGN. So in my C function right
> before the popen call I set the signal handler for SIGCHLD to SIG_DFL
> and right after the pclose I set it back to SIG_IGN. I tested this
> and it seems to solve my problem.
Hmm. A possibly related bit of ugliness can be found in
src/backend/commands/dbcommands.c, where we ignore ECHILD after
a system() call:
ret = system(buf); /* Some versions of SunOS seem to return ECHILD after a system() call */ if (ret != 0 &&
errno!= ECHILD) {
Interesting, no? I wonder whether we could get rid of that kluge
if the signal handler was SIG_DFL rather than SIG_IGN. Can anyone
try this on one of the affected versions of SunOS? (Tatsuo, you
seem to have added the ECHILD exception on May 25 2000; the commit
message mentions Solaris but not which version. Could you try it?)
What I'd be inclined to do, rather than swapping the handlers around
while running, is to just have backend startup (tcop/postgres.c) set
the handler to SIG_DFL not SIG_IGN in the first place. That *should*
produce the identical results according to my man pages, but evidently
it's not quite the same thing on some systems.
Changing this might be a zero-cost solution to a portability glitch.
Comments anyone?
regards, tom lane