From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to handle waitingForLock in LockWaitCancel() |
Date: | 2001-03-06 02:14:32 |
Message-ID: | 3AA44808.870E21F9@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> 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.
>
Agreed. Adding similar code to QueryCancelHandler seems
sufficient.
> I suspect you will find that these crashes occur during the window just
> after
Sorry what does 'just after' mean ?
Isn't it during the semop() ?
> the semop() call in IpcSemaphoreLock() --- see the comment
Regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Myers | 2001-03-06 02:19:25 | Re: How to shoot yourself in the foot: kill -9 postmaster |
Previous Message | Bruce Momjian | 2001-03-06 02:14:16 | Re: How to shoot yourself in the foot: kill -9 postmaster |