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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
