Re: Is the unfair lwlock behavior intended?
От | Robert Haas |
---|---|
Тема | Re: Is the unfair lwlock behavior intended? |
Дата | |
Msg-id | CA+TgmoZ-gy2igiGeemM9tC46s6RJNc8_Yrp8W81pG98jSEkWtQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Is the unfair lwlock behavior intended? (Ants Aasma <ants.aasma@eesti.ee>) |
Ответы |
Re: Is the unfair lwlock behavior intended?
|
Список | pgsql-hackers |
On Tue, May 24, 2016 at 4:39 PM, Ants Aasma <ants.aasma@eesti.ee> wrote: > On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki > <tsunakawa.takay@jp.fujitsu.com> wrote: >> I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. That appears to apply to 9.6, too, as far asI examine the code. Could you tell me if the behavior is intended or needs fix? >> >> Simply put, the unfair behavior is that waiters for exclusive mode are overtaken by share-mode lockers who arrive later. > > 9.5 had significant LWLock scalability improvements. This might > improve performance enough so that exclusive lockers don't get > completely starved. It would be helpful if you could test if it's > still possible to trigger starvation with the new code. 9.5 didn't just increase the scalability; it also whacked the fairness aspects of this code around. Author: Andres Freund <andres@anarazel.de> Branch: master Release: REL9_5_BR [7882c3b0b] 2014-12-25 17:24:30 +0100 Convert the PGPROC->lwWaitLink list into a dlist instead of open coding it. Besides being shorter and much easier to read it changes the logic in LWLockRelease() to release all shared lockerswhen waking up any. This can yield some significant performance improvements - and the fairness isn't really muchworse than before, as we always allowed new shared lockers to jump the queue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: