On Fri, Dec 11, 2015 at 6:34 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2015-12-11 15:56:46 +0300, Alexander Korotkov wrote: > > > > Yes, there is a cycle with retries in LWLockAcquire function. The case of > > retry is when waiter is waked up, but someone other steal the lock before > > him. Lock waiter is waked up by lock releaser only when lock becomes free. > > But in the case of high concurrency for shared lock, it almost never > > becomes free. So, exclusive locker would be never waked up. I'm pretty sure > > this happens on big Intel machine while we do the benchmark. So, relying on > > number of retries wouldn't work in this case. > > I'll do the tests to verify if retries happens in our case.
makes sense and if retries never happen, then I think changing LWLockRelease() such that it should wake the waiters if there are waiters on a lock and it has not waked them for some threshold number of times or something like that might work. > > I seriously doubt that making lwlocks fairer is the right way to go > here. In my testing the "unfairness" is essential to performance - the > number of context switches otherwise increases massively. > Agreed, if the change being discussed hurts in any kind of scenario, then we should better not do it, OTOH the case described by Alexander seems to be genuine and I have seen similar complaint by customer in the past for another database I worked with and the reason for the problem is same. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
