On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
> Stephen Harris <[EMAIL PROTECTED]> writes:
> > Why not, after calling fork() create a new process group with setsid() and
> > then instead of killing the recovery thread, kill the whole process group
> > (-PID rather than PID)? Then every
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, I tried to test that before I sent that. But I guess my test was faulty
> since I was really testing what process the terminal handling delivered the
> signal to:
Interesting. I tried the same test on HPUX, and find that its /bin/sh
seems to ignore
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Sure, but it might be getting delivered to, say, your "sleep" command. You
>> haven't checked the return value of sleep to handle any errors that may
>> occur.
>> As it stands you have to check for errors from e
Gregory Stark <[EMAIL PROTECTED]> writes:
> Sure, but it might be getting delivered to, say, your "sleep" command. You
> haven't checked the return value of sleep to handle any errors that may occur.
> As it stands you have to check for errors from every single command executed
> by your script.
T
Stephen Harris <[EMAIL PROTECTED]> writes:
> On Fri, Nov 17, 2006 at 10:49:39PM -0500, Tom Lane wrote:
>> This does not apply to signals originated by the postmaster --- it
>> doesn't even know that the child process is doing a system(), much less
>> have any way to signal the grandchild. Ugh.
>
On Fri, Nov 17, 2006 at 10:49:39PM -0500, Tom Lane wrote:
> Stephen Harris <[EMAIL PROTECTED]> writes:
> > However, it seems the signal wasn't sent at all.
>
> Now that I think about it, the behavior of system() is predicated on the
> assumption that SIGINT and SIGQUIT originate with the tty drive
On Fri, Nov 17, 2006 at 09:39:39PM -0500, Gregory Stark wrote:
> "Stephen Harris" <[EMAIL PROTECTED]> writes:
> > [...variable setup...]
> > while [ ! -f $wanted_file ]
> > do
> > if [ -f $abort_file ]
> > then
> > exit 1
> > fi
> > sleep 5
> > done
> > cat $wanted_f
Stephen Harris <[EMAIL PROTECTED]> writes:
> However, it seems the signal wasn't sent at all.
Now that I think about it, the behavior of system() is predicated on the
assumption that SIGINT and SIGQUIT originate with the tty driver and are
broadcast to all members of the session's process group --
"Stephen Harris" <[EMAIL PROTECTED]> writes:
> My script was just a ksh script and didn't do anything special with signals.
> Essentially it does
> #!/bin/ksh -p
>
> [...variable setup...]
> while [ ! -f $wanted_file ]
> do
> if [ -f $abort_file ]
> then
> exit 1
> fi
>
On Fri, Nov 17, 2006 at 05:03:44PM -0500, Tom Lane wrote:
> Stephen Harris <[EMAIL PROTECTED]> writes:
> > Doing a shutdown "immediate" isn't to clever because it actually leaves
> > the recovery threads running
>
> > LOG: restored log file "00010001003E" from archive
> > LOG: receiv
Stephen Harris <[EMAIL PROTECTED]> writes:
> Doing a shutdown "immediate" isn't to clever because it actually leaves
> the recovery threads running
> LOG: restored log file "00010001003E" from archive
> LOG: received immediate shutdown request
> LOG: restored log file "00010
11 matches
Mail list logo
