On Sun, Dec 13, 2015 at 11:05 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Dec 11, 2015 at 6:34 PM, Andres Freund <andres@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.
I have moved this patch to next CF..
--
Michael