Gregory Stark <stark@xxxxxxxxxxxxxxxx> 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
