Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I'm somewhat surprised that HPUX does not --- it tends to follow its
>> SysV heritage when there's a conflict between that and BSD practice.
>> Guess they went BSD on this one.
> I thought HPUX was mostly SysV tools on BSD kernel.
No, it was all SysV
> Bill Studenmund <[EMAIL PROTECTED]> 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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The auto-reaping is standard SysV behavior, while BSD is really ignore.
You'll recall the ECHILD exception was installed by Tatsuo after seeing
problems on Solaris. Evidently Solaris uses the auto-reap behavior too.
I'm somewhat surprised that HPUX d
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The auto-reaping is standard SysV behavior, while BSD is really ignore.
>
> You'll recall the ECHILD exception was installed by Tatsuo after seeing
> problems on Solaris. Evidently Solaris uses the auto-reap behavior too.
SVr4/Solaris took the Sy
On Mon, 30 Jul 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> 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,
Bill Studenmund <[EMAIL PROTECTED]> 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 s
Bill Studenmund <[EMAIL PROTECTED]> 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
On Mon, 30 Jul 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > All ECHILD is doing is saying there was no child. Since we aren't really
> > waiting for the child, I don't see how that's a problem.
>
> You're missing the point: on some platforms the system() call is
> retur
Bill Studenmund <[EMAIL PROTECTED]> writes:
> All ECHILD is doing is saying there was no child. Since we aren't really
> waiting for the child, I don't see how that's a problem.
You're missing the point: on some platforms the system() call is
returning a failure indication because of ECHILD. It'
On Sun, 22 Jul 2001, Tatsuo Ishii wrote:
> > [EMAIL PROTECTED] 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 c
> [EMAIL PROTECTED] 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
> > h
[EMAIL PROTECTED] 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
I was wondering if some of you Postgres hackers could advise me on the
safety of the following. 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
13 matches
Mail list logo
