Re: SIGCHLD handler in Postgres C function.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: spshealy(at)yahoo(dot)com
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SIGCHLD handler in Postgres C function.
Date: 2001-07-17 17:21:34
Message-ID: 25603.995390494@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

spshealy(at)yahoo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-07-17 17:31:16 Re: Idea: recycle WAL segments, don't delete/recreate 'em
Previous Message Bruce Momjian 2001-07-17 16:46:35 Re: pg_depend