Re: Is the unfair lwlock behavior intended? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Is the unfair lwlock behavior intended?
Date
Msg-id CA+TgmoZ-gy2igiGeemM9tC46s6RJNc8_Yrp8W81pG98jSEkWtQ@mail.gmail.com
Whole thread Raw
In response to Re: Is the unfair lwlock behavior intended?  (Ants Aasma <ants.aasma@eesti.ee>)
Responses Re: Is the unfair lwlock behavior intended?  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
Next
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind