From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Move PinBuffer and UnpinBuffer to atomics |
Date: | 2015-12-13 14:05:11 |
Message-ID: | CAA4eK1+xymdSG7ARsKLFG9ANYTWeLRnSM0Z6FkViDH7codeM_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 11, 2015 at 6:34 PM, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-12-13 14:16:03 | Re: strange CREATE INDEX tab completion cases |
Previous Message | David Fetter | 2015-12-13 13:43:24 | Re: Tee for COPY |