Buffer Pool and Eviction
Lesson, slides, and applied problem sets.
View SlidesLesson
Buffer Pool and Eviction
Why this module exists
Disks are slow. The buffer pool caches pages in memory, but caching introduces correctness rules: dirty pages, pin counts, eviction, and the WAL ordering constraint.
1) Pinning and eviction
When a page is in use, it is pinned and must not be evicted. Only unpinned pages are eviction candidates.
LRU (least recently used) is a common policy, but it must ignore pinned pages. If all pages are pinned, the buffer pool must refuse to load more pages.
2) Dirty pages and flush order
A dirty page has in-memory changes not yet persisted. Before flushing a dirty page, the WAL must already contain the corresponding log records (WAL rule).
Even in this toy pack, the buffer pool must track dirty state and only evict when safe.
3) LRU is a policy, not a contract
LRU optimizes for temporal locality. It is not always optimal, but it is predictable and easy to reason about. Correctness depends on respecting pins and dirty state, not on the exact policy.
What you will build
- A buffer pool simulator with pins, dirty flags, and LRU eviction.
Key takeaways
- Pin counts are correctness, not optimization.
- Eviction is a policy layered on correctness rules.
- WAL ordering constrains when dirty pages can be flushed.