BM optimistic reads

[ray6080]

This PR adds optimisticRead interface to BM following the VMCache design. Any writes to file pages should go through pin/unpin, and reads can go through optimisticRead, which lifts the read-read lock contentions.

Page states and versions

Pages managed by BM now have four states: a) Locked, b) Unlocked, c) Marked, d) Evicted.
Every page is initialized as in the Evicted state. When a page is pinned, it transits to the Locked state.
When the caller finishes changes to the page, it calls unpin, which releases the lock on the page, thus, the page transits to the Unlocked state.
Any optimistic reads on Unlocked pages should not make any changes to the page, and reads on Marked pages will first set their states to Unlocked, and then read the page optimistically. For Evicted pages, optimistic reads will trigger pin and unpin to read pages from disk into frames.

Besides the page state, each page also has a version number. The version number is used to identify any potential writes on the page. Each time a page transits from Locked to Unlocked state, it will increment its version. When a page is pinned, then unpinned, it will transit from Locked to the Unlocked state, and its version will be incremented. During the pin and unpin, we assume the page's content in its corresponding frame might have changed, thus, we increment the version number to forbid stale reads on it.

Eviction

We still use queue-based eviction strategy.
To track pages that can potentially be evicted, we push unlocked pages into the eviction queue, and set their states to Marked, which means they are ready to be evicted.
After the candidate was enqueued:

1. if the page's version has changed, which indicates that the page was pinned and unpinned again, the candidate should be discarded. Due to that there should be another candidate pointing to the same page in the queue.
2. if the page's state is Unlocked, but its version hasn't changed, which indicates that the page was optimistically read, the page should be set to Marked and the candidate should be moved back to the queue.

[codecov]

Codecov Report

Patch coverage: 92.51% and project coverage change: +0.03 🎉

Comparison is base (3f574a4) 92.71% compared to head (58265f9) 92.74%.

❗ Current head 58265f9 differs from pull request most recent head 3d782ad. Consider uploading reports for the commit 3d782ad to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1409      +/-   ##
==========================================
+ Coverage   92.71%   92.74%   +0.03%     
==========================================
  Files         642      642              
  Lines       22102    22126      +24     
==========================================
+ Hits        20491    20521      +30     
+ Misses       1611     1605       -6     

Impacted Files	Coverage Δ
...ude/storage/storage_structure/disk_overflow_file.h	100.00% <ø> (ø)
src/storage/buffer_manager/bm_file_handle.cpp	98.82% <ø> (+0.92%)	⬆️
src/storage/buffer_manager/buffer_manager.cpp	80.18% <79.06%> (+4.32%)	⬆️
...rc/include/storage/buffer_manager/buffer_manager.h	86.66% <83.33%> (+13.33%)	⬆️
...c/storage/storage_structure/disk_overflow_file.cpp	95.37% <93.75%> (+0.05%)	⬆️
...rc/include/storage/buffer_manager/bm_file_handle.h	100.00% <100.00%> (+4.54%)	⬆️
src/storage/storage_structure/column.cpp	91.79% <100.00%> (ø)
src/storage/storage_structure/disk_array.cpp	93.41% <100.00%> (-0.03%)	⬇️
src/storage/storage_structure/lists/lists.cpp	98.00% <100.00%> (+0.09%)	⬆️
...rc/storage/storage_structure/storage_structure.cpp	100.00% <100.00%> (ø)
... and 1 more

... and 2 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.