On Fri, Apr 5, 2013 at 1:12 AM, Amit Kapila <amit.kap...@huawei.com> wrote: > If we just put it to freelist, then next time if it get allocated directly > from bufhash table, then who will remove it from freelist > or do you think that, in BufferAlloc, if it gets from bufhash table, then it > should verify if it's in freelist, then remove from freelist.
No, I don't think that's necessary. We already have the following guard in StrategyGetBuffer: if (buf->refcount == 0 && buf->usage_count == 0) { if (strategy != NULL) AddBufferToRing(strategy, buf); return buf; } If a buffer is allocated from the freelist and it turns out that it actually has a non-zero reference count or a non-zero pin count, we just discard it and pull the next buffer off the freelist instead. So, in the scenario you describe, the buffer gets reallocated (due to a non-NULL BufferAccessStrategy, presumably) and then somebody comes a long and pulls it off the freelist. But, since the buffer has just been used by someone else, it'll most likely be pinned or have a non-zero usage count, so we'll just skip it and allocate some other buffer instead. No harm done. Now, it is possible that the buffer could get added to the freelist, then allocated via a BufferAccessStrategy, and then the clock sweep could hit it and push the usage count back to 0. But that's no big deal either: if we go to put it on the freelist and see (via buf->freeNext) that it's already there, we can just leave it where it is (or maybe move it to the end). On a related note, we probably need a variant of StrategyFreeBuffer which pushes buffers onto the end of the freelist rather than the front. It makes sense to stick invalidated buffers on the front of the list (which is what StrategyFreeBuffer does), but non-invalidated buffers should be placed at the end to more closely approximate LRU. -- 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