On Sun, Dec 13, 2015 at 11:05 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > 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.
I have moved this patch to next CF.. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
