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
