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 по дате отправления: