LWLockAcquire with priority
От | Simon Riggs |
---|---|
Тема | LWLockAcquire with priority |
Дата | |
Msg-id | 1223635679.7007.178.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответы |
Re: LWLockAcquire with priority
|
Список | pgsql-hackers |
Thinking about how to reduce the effects of certain race conditions makes me think about whether it is possible to make a function called LWLockAcquireWithPriority(). We already allow "queue jumping" when lock mode != LW_EXCLUSIVE, so queue jumping based upon an assigned priority rather than arrival time might also work. If we maintain two tails, rather than one, we can allow two entry points onto the lock queue. One is a "fast track" entry point for hi priority requests, while the other is the normal track for most requests. I would propose we use this: * on WALInsertLock requests for commit (not abort) * on WALInsertLock and SLRU requests for ExtendCLog, ExtendMultiXactOffset, ExtendMultiXactMember This will prevent commits being stalled when we occasionally switch clog and multixact pages, plus it also stops commits from being stalled when there are heavy writers in progress. If we use this only on certain locks, we can use macros to make LWLockAcquire point to the new function without changes to most code. So we have new function LWLockAcquireWithPriority(LWLockId lockid, LWLockMode mode, bool hipriority) and LWLockAcquireWithoutPriority(LWLockId lockid, LWLockMode mode) LWLockAcquire() maps to LWLockAcquireWithoutPriority for all locks except for WALInsertLock and SLRU locks, which map to LWLockAcquireWithPriority(x, x, false) LockAcquireWithPriority(x, x, true) would then be used in key places as suggested above. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: