From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | YUriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Move PinBuffer and UnpinBuffer to atomics |
Date: | 2015-09-15 16:47:40 |
Message-ID: | 20150915164740.GA2086@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-09-15 19:43:28 +0300, YUriy Zhuravlev wrote:
> On Tuesday 15 September 2015 16:50:44 Andres Freund wrote:
> > No, they can't in a a relevant manner. We hold the buffer header lock.
> I'm sorry, I did not notice of a LockBufHdr.
>
> In this embodiment, your approach seems to be very similar to s_lock. Cycle in
> PinBuffer behaves like s_lock.
> In LockBufHdr:
> if (pg_atomic_compare_exchange_u32(&desc->state, &state, state | BM_LOCKED))
>
> conflict with:
> while (unlikely(state & BM_LOCKED))
> from PinBuffer.
> Thus your patch does not remove the problem of competition for PinBuffer.
> We will try check your patch this week.
That path is only taken if somebody else has already locked the buffer
(e.g. BufferAlloc()). If you have contention in PinBuffer() your
workload will be mostly cache resident and neither PinBuffer() nor
UnpinBuffer() set BM_LOCKED.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Anastasia Lubennikova | 2015-09-15 16:57:24 | Re: [PROPOSAL] Covering + unique indexes. |
Previous Message | Ildus Kurbangaliev | 2015-09-15 16:44:19 | Re: [PATCH] Refactoring of LWLock tranches |