Re: How to handle waitingForLock in LockWaitCancel()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: How to handle waitingForLock in LockWaitCancel()
Дата
Msg-id 20376.983821400@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: How to handle waitingForLock in LockWaitCancel()  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Список pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> [ backtrace snipped ]

Hmm, this is definitely not operating as intended: LockWaitCancel is
getting interrupted, because ProcessInterrupts may be called when it's
trying to acquire the lockmanager spinlock, and ProcessInterrupts will
see the ProcDiePending flag already set.  I think the correct fix (or
at least part of it) is in postgres.c's die():
       /*        * If it's safe to interrupt, and we're waiting for input or a lock,        * service the interrupt
immediately       */       if (ImmediateInterruptOK && InterruptHoldoffCount == 0 &&           CritSectionCount == 0)
   {
 
+           /* bump holdoff count to make ProcessInterrupts() a no-op */
+           /* until we are done getting ready for it */
+           InterruptHoldoffCount++;           DisableNotifyInterrupt();           /* Make sure HandleDeadLock won't
runwhile shutting down... */           LockWaitCancel();
 
+           InterruptHoldoffCount--;           ProcessInterrupts();       }

QueryCancelHandler probably needs similar additions.

I suspect you will find that these crashes occur during the window just
after the semop() call in IpcSemaphoreLock() --- see the comment
beginning at line 399 of ipc.c.  You could probably make the crash
easier to reproduce by inserting a delay there, if you want to test
more.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ian Lance Taylor
Дата:
Сообщение: Re: WAL-based allocation of XIDs is insecure
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WAL-based allocation of XIDs is insecure