Buffer Pool and Eviction

Lesson, slides, and applied problem sets.

View Slides

Lesson

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.

Module Items