Re: [HACKERS] Which signal to use for CANCEL from postmaster to backend?

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> All three of SIGINT, SIGHUP, SIGTERM currently do the same thing in a
>> backend, so it looks like our best choice is to redefine one of those
>> as the cancel request signal. Any preference?

> I like SIGQUIT. Looks to be unused. SIGINT is used too much from the
> command line, and SIGTERM used too much from scripts (the default kill
> arg.)

I've been thinking about it a little more, and on the whole I like using
SIGINT the best. Here's my reasoning:

1. SIGINT is not normally generated for non-interactive processes,
so for the ordinary case of a backend running under the postmaster
it wouldn't be generated by accident. (As you point out, the default
signal from kill(1) is SIGTERM not SIGINT.)

2. The only case where it *would* be easy to direct SIGINT to a backend
is in the case of a backend hand-invoked from the command line. In this
case I think that having control-C do a Cancel rather than kill the
process is a fine idea --- it is exactly parallel to the behavior that
psql now offers. People will probably get used enough to psql's
behavior that having an interactive backend work differently would be
a bad idea.

3. SIGQUIT normally generates a coredump, and is one of the few
non-error signals that do so. If we use it for the cancel signal we
will eliminate the easiest, most standard way of externally forcing a
backend to coredump. That seems like a loss of a useful debug tool.
Also, in all Unix applications that I'm familiar with, SIGQUIT is a
"more severe" signal than SIGINT --- one expects that an app may trap
SIGINT and return keyboard control, but SIGQUIT is supposed to kill it.
Inverting the severity of SIGINT and SIGQUIT for a pgsql backend doesn't
sound like a good plan.

So I think we should leave SIGTERM and SIGQUIT alone, and redefine
SIGINT to perform a cancel.

BTW, I realized that SIGHUP is not really free, it's what is used to
return control from elog(ERROR) to the main loop. The code probably
should refer to it as SIGHUP not signal "1".

regards, tom lane

PS: I've got these changes coded up, and am about to start testing.