On 2015-09-14 13:16:46 +0300, YUriy Zhuravlev wrote: > On Friday 11 September 2015 18:50:35 you wrote:
> > a) As I said upthread there's a patch to remove these locks entirely > It is very interesting. Could you provide a link? http://archives.postgresql.org/message-id/CA%2BTgmoYE4t-Pt%2Bv08kMO5u_XN-HNKBWtfMgcUXEGBrQiVgdV9Q%40mail.gmail.com > And it's not very good, > since there is a bottleneck PinBuffer / UnpinBuffer instead of > LWLocks. Where the bottleneck is entirely depends on your workload. If you have a high cache replacement ratio the mapping partition locks are frequently going to be held exclusively. > > b) It doesn't matter anyway. Not every pin goes through the buffer > > mapping table. StrategyGetBuffer(), SyncOneBuffer(), ... > StrategyGetBuffer call only from BufferAlloc . It gets called without buffer mapping locks held. And it can (and frequently will!) access all the buffers in the buffer pool. > SyncOneBuffer not problem too because: > PinBuffer_Locked(bufHdr); Which you made ineffective because PinBuffer() doesn't take a lock anymore. Mutual exclusion through locks only works if all participants take the locks. > We checked all functions with refcount and usage_count. Adding lockless behaviour by just taking out locks without analyzing the whole isn't going to fly. You either need to provide backward compatibility (a LockBuffer that provides actual exclusion) or you actually need to go carefully through all relevant code and make it lock-free. I pointed out how you can actually make this safely lock-free giving you the interesting code. 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
