On Tue, May 8, 2012 at 9:37 PM, Amit Kapila <amit.kap...@huawei.com> wrote: > I have checked the code and logic according to which usage counter is > increased when the buffer is pinned.
Fixed, thanks for the report. > Another Doubt : Why in function BufferAlloc, it needs to hold the > BufFreelistLock till it pin the buffer which increases its reference count. Well, I think the problem is that, if we didn't do that, then, in theory, the strategy point could wrap all the way around shared_buffers and someone else could pin the buffer, and then we'd be hosed. Mind you, I think this whole area of the code needs some reengineering for better performance, but I'm not sure this is the right place to start. What I think is really bad is that we're forcing every BufferAlloc() to iterate over buffers checking whether each one is evictable. I think we ought to put only those buffers that we think are likely to be evictable on the freelist, and then the actual buffer eviction code would only need to recheck that nothing had changed, instead of needing to scan over a potentially quite large number of buffers that never had any chance of being selected in the first place. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
