Skip site navigation (1) Skip section navigation (2)

Re: How to handle waitingForLock in LockWaitCancel()

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: (view raw, whole thread or download thread mbox)
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++;
            /* Make sure HandleDeadLock won't run while shutting down... */
+           InterruptHoldoffCount--;

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

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-05 20:02:36
Subject: Re: WAL-based allocation of XIDs is insecure
Previous:From: Ian Lance TaylorDate: 2001-03-05 19:35:56
Subject: Re: WAL-based allocation of XIDs is insecure

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group