Re: Are we accepting cancel interrupts too often?
От | Bruce Momjian |
---|---|
Тема | Re: Are we accepting cancel interrupts too often? |
Дата | |
Msg-id | 200112311614.fBVGEXb26696@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Are we accepting cancel interrupts too often? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Presently, the RESUME_INTERRUPTS() and END_CRIT_SECTION() macros implicitly > do a CHECK_FOR_INTERRUPTS(); that is, if a cancel request arrived during > the interrupt-free section it will be serviced immediately upon exit > from the section. > > It strikes me that this is a really bad idea. There are lots of places > where we release one lock then acquire another, and are not expecting to > lose control in between. The original concept of the query-cancel > facility was that we'd accept cancels only at *explicit* > CHECK_FOR_INTERRUPTS points. What we actually have at the moment is > that cancels could be accepted in a very wide variety of places, and > I don't believe we've considered the consequences at each such place. > > I am inclined to remove the ProcessInterrupts calls from > RESUME_INTERRUPTS and END_CRIT_SECTION. Does anyone object? I read the nice description of RESUME_INTERRUPTS at the top of miscadmin.c and I agree that the idea of allowing a CHECK_FOR_INTERRUPTS call is not the same as making the call. I started to look at when this nice code was added to determine if this was part of the original design or added later and found you wrote it yourself, so I guess we don't have to ask anyone to make sure there isn't something were are missing. Looking at CHECK_FOR_INTERRUPTS calls, those are all in safe places, while the RESUME_INTERRUPTS are not in obviously safe places, so I agree with your suggested change. --------------------------------------------------------------------------- Revision 1.77 / (download) - annotate - [select for diffs] , Sun Jan 14 05:08:16 2001 UTC (11 months, 2 weeks ago) by tgl Changes since 1.76: +73 -36 lines Diff to previous 1.76 Restructure backend SIGINT/SIGTERM handling so that 'die' interrupts are treated more like 'cancel' interrupts: the signal handler sets a flag that is examined at well-defined spots, rather than trying to cope with an interrupt that might happen anywhere. See pghackers discussion of 1/12/01. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: