On Fri, Apr 5, 2013 at 1:12 AM, Amit Kapila <amit.kapila@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