"Stephen Harris" <lists@xxxxxxxxxx> 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
