some questions about fast-path-lock
| От | Alex |
|---|---|
| Тема | some questions about fast-path-lock |
| Дата | |
| Msg-id | CAKU4AWqxd1hceB8jpWkmCFbZ+38Aqh_xEkPfa9STihV86o-xyQ@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: some questions about fast-path-lock
|
| Список | pgsql-hackers |
I got some idea from the README under storage/lmgr and read some code of LockAcquireExtended , but I still have some questions now.
acquired = false;
else
acquired = FastPathGrantRelationLock(locktag->locktag_field2,
lockmode);
spinlock. Otherwise, this effort would simply move the contention bottleneck
from one place to another."
LWLockAcquire(&MyProc->backendLock, LW_EXCLUSIVE);
if (FastPathStrongRelationLocks->count[fasthashcode] != 0)acquired = false;
else
acquired = FastPathGrantRelationLock(locktag->locktag_field2,
lockmode);
1. In the README, it says: "A key point of this algorithm is that it must be possible to verify the
absence of possibly conflicting locks without fighting over a shared LWLock orspinlock. Otherwise, this effort would simply move the contention bottleneck
from one place to another."
but in the code, there is LWLockAcquire in the above code. Actually I can't think out how can we proceed without a lock.
2. Why does the MyProc->backendLock work? it is MyProc not a global lock.
3. for the line, acquired = FastPathGrantRelationLock(locktag->locktag_field2,
lockmode); I think it should be able to replaced with "acquired = true" (but obviously I'm wrong) . I read "FastPathGrantRelationLock" but can't understand it. Any hint will be helpful. thanks!
В списке pgsql-hackers по дате отправления: