A question regarding LWLock in ProcSleep
От | Kenan Yao |
---|---|
Тема | A question regarding LWLock in ProcSleep |
Дата | |
Msg-id | CAO1BoPwHnPsmaG+ifg=zOYt0xSigVW==Ye=Bo2NP_scAHGwAsA@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: A question regarding LWLock in ProcSleep
|
Список | pgsql-hackers |
Hi there,
In function ProcSleep, after the process has been waken up, either with lock granted or deadlock detected, it would re-acquire the lock table's partition LWLock.
The code episode is here:
/* * Re-acquire the lock table's partition lock. We have to do this to hold * off cancel/die interrupts before we can mess with lockAwaited (else we * might have a missed or duplicated locallock update). */ LWLockAcquire(partitionLock, LW_EXCLUSIVE);
/* * We no longer want LockErrorCleanup to do anything. */ lockAwaited = NULL;
/* * If we got the lock, be sure to remember it in the locallock table. */ if (MyProc->waitStatus == STATUS_OK) GrantAwaitedLock();
/* * We don't have to do anything else, because the awaker did all the * necessary update of the lock table and MyProc. */ return MyProc->waitStatus;
Questions are:
(1) The comment says that "we might have a missed or duplicated locallock update", in what cases would we hit this if without holding the LWLock?
(2) The comment says "we have to do this to hold off cancel/die interrupts", then:
- why using LWLockAcquire instead of HOLD_INTERRUPTS directly?
- From the handler of SIGINT and SIGTERM, seems nothing serious would be processed here, since no CHECK_FOR_INTERRUPS is called before releasing this LWLock. Why we should hold off cancel/die interrupts here?
Apologize if I missed anything here, and appreciate if someone can help me on this question. Thanks
Cheers,
Kenan
В списке pgsql-hackers по дате отправления: