Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
От | Heikki Linnakangas |
---|---|
Тема | Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful |
Дата | |
Msg-id | 538799B8.70708@vmware.com обсуждение исходный текст |
Ответ на | CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful |
Список | pgsql-hackers |
On 05/29/2014 11:25 PM, Tom Lane wrote: > One of the annoying things about the SPGiST bug Teodor pointed out is > that once you're in the infinite loop, query cancel doesn't work to get > you out of it. There are a couple of CHECK_FOR_INTERRUPTS() calls in > spgdoinsert() that are meant to get you out of exactly this sort of > buggy-opclass situation --- but they don't help. The reason is that > when we reach that point we're holding one or more buffer locks, which > means the HOLD_INTERRUPTS count is positive, so ProcessInterrupts is > afraid to do anything. > > In point of fact, we'd be happy to give up the locks and then throw > the error. So I was thinking about inventing some macro or out-of-line > function that went about like this: > > if (InterruptPending && (QueryCancelPending || ProcDiePending)) > { > LWLockReleaseAll(); > ProcessInterrupts(); > elog(ERROR, "ProcessInterrupts failed to throw an error"); > } > > where we don't expect to reach the final elog; it's just there to make > sure we don't return control after yanking locks out from under the > caller. Also checking that CritSectionCount == 0 seems like a good idea... - Heikki
В списке pgsql-hackers по дате отправления: