"Stephen Harris" <lists@spuddy.org> 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
> sleep 5
> done
> cat $wanted_file
>
> I know signals can be deferred in scripts (a signal sent to the script during
> the sleep will be deferred if a trap handler had been written for the signal)
> but they _do_ get delivered.
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.
That doesn't seem terribly practical to expect of useres. As long as Postgres
is using SIGQUIT for its own communication it seems it really ought to arrange
to block the signal while the script is running so it will receive the signals
it expects once the script ends.
Alternatively perhaps Postgres really ought to be using USR1/USR2 or other
signals that library routines won't think they have any business rearranging.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
