Gregory Stark <stark@enterprisedb.com> 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.
The expectation is that something like SIGINT or SIGQUIT would be
delivered to both the sleep command and the shell process running the
script. So the shell should fail anyway. (Of course, a nontrivial
archive or recovery script had better be checking for failures at each
step, but this is not very relevant to the immediate problem.)
> Alternatively perhaps Postgres really ought to be using USR1/USR2 or other
> signals that library routines won't think they have any business rearranging.
The existing signal assignments were all picked for what seem to me
to be good reasons; I'm disinclined to change them. In any case, the
important point here is that we'd really like an archive or recovery
script, or for that matter any command executed via system() from a
backend, to abort when the parent backend is SIGINT'd or SIGQUIT'd.
Stephen's idea of executing setsid() at each backend start seems
interesting, but is there a way that will work on Windows?
regards, tom lane
