Re: [HACKERS] Which signal to use for CANCEL from postmaster to backend?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Which signal to use for CANCEL from postmaster to backend? |
Дата | |
Msg-id | 199807072201.SAA11640@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Which signal to use for CANCEL from postmaster to backend? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> 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. All very good points. SIGINT is good. > > > 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". Patch applied. > > regards, tom lane > > PS: I've got these changes coded up, and am about to start testing. > Cool. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: