Buffer pools: one page, three different questions

  • Residency: is it cached?
  • Pin count: may its frame be replaced?
  • Dirty state: does this copy contain writes?

Predict: two fetches of page A, one unpin. Can A be evicted?

1 / 8

A pin is a count

fetch A     pin=1
fetch A     pin=2
unpin A     pin=1

A is still in use. A pin does not provide transaction isolation.

2 / 8

Choose among eligible frames

Capacity 2; recency is oldest → newest:

Page Pin count Dirty
A 1 false
B 0 true

Fetch C: evict B, reporting dirty=true.

The oldest page is not necessarily the oldest eligible page.

3 / 8

Recency and release are different events

fetch/unpin A
fetch/unpin B
fetch/unpin A
unpin B again
fetch C

Predict the victim before advancing.

4 / 8

B leaves

A's second fetch made it most recent. Unpin does not refresh recency.

A clean unpin also does not clear an earlier dirty flag.

Check these as separate invariants; a single “last touched” field can encode the wrong policy.

5 / 8

Both frames pinned → fetch fails.

  • Return prior evictions and ok=false.
  • Execute no later operations.
  • Never force-evict an in-use page.

An empty operation list still succeeds at capacity zero.

6 / 8

Dirty eviction has a persistence boundary

Real page: pageLSN=42, durable WAL ends at 39.

flush WAL through 42 → write page → reuse frame

The exercise reports a dirty victim. Its API does not simulate either flush.

7 / 8

Review a design

Map + ordered slice: O(MC) time, O(C) resident metadata.

Explain how your code preserves:

  1. One list entry per resident page.
  2. Nonnegative pin counts.
  3. Dirty flags across clean unpins.
  4. Victim choice after skipping pinned pages.

Then implement buffer-pool and reproduce the lesson's nine-step trace.

8 / 8
←/→ or click edges to navigate · ? help · N notes · F fullscreen