From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to handle waitingForLock in LockWaitCancel() |
Date: | 2001-03-05 19:43:20 |
Message-ID: | 20376.983821400@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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 run while 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-05 20:02:36 | Re: WAL-based allocation of XIDs is insecure |
Previous Message | Ian Lance Taylor | 2001-03-05 19:35:56 | Re: WAL-based allocation of XIDs is insecure |