Description
Some students (both on Piazza and in OH) have misinterpreted the FlushPage documentation to mean that we want to evict the entire page from memory, rather than just sync to disk. Since it's not explicitly stated otherwise, we should probably add that documentation change in.
Additionally, the FlushPage API makes it possible for someone to implement it incorrectly with a race condition: If someone holds a WritePageGuard and is modifying the page, an incorrect FlushPage could flush inconsistent state out to disk.
Some thoughts: https://piazza.com/class/lzk4t7ue1bu5ph/post/208
I think the ideal solution is somewhere in between. We could have FlushPage methods on both ReadPageGuard and WritePageGuard that can safely flush to disk, as well as methods on the buffer pool manager that both “eagerly” flush to disk and safely flush to disk after taking the latch on the page we want to flush (and two methods on the BPM for flushing all pages).
What my implementation does is only flush in the case that the flushing thread is the only thread that has access to the page, delaying the flush to another time. Is this a good solution? No, but it is not unsafe. If I wanted to be more correct, I could also set a flag during FlushPage that notifies any current threads accessing the page that a flush request has occurred, and now it is their job to flush safely.