page_num may be -1 when creating index

ycycse commented 3 months ago

当涉及数据过多，索引创建涉及页的驱逐时，我们发现，存在页的page_num为-1。这会导致驱逐时的刷盘错误，或是该页永远无法被驱逐，会一直占用LRU的一个frame。

对日志进行打印，发现page_num被异常设置为-1.

对于新分配的Page_num，我们会将其设置为page_count数，理论上这是一个递增的过程，不应该出现page_num突然为-1的情况，因此推断为一个Bug。

file_header_->allocated_pages++;
file_header_->page_count++;
PageNum num = file_header_->page_count - 1;

hotwords123 commented 3 months ago

这个 bug 可能和 #17 有关，之前我也是在 Lab2 中测试大批量加入数据时发现的这个 bug。

具体原因是：

如果 Lab1 的实现中 evict_all_pages 没有判断 pin_count 就释放了页面（或者使用了实际上不能工作的 ASSERT，见 #18），则 B+ 树索引文件的 header frame（page 0，记录页面分配信息）会被错误释放，如 #17 中所述。
LRU Cache 的策略是把被释放的页面放在链表尾，因此直到占满页面池后这个错误释放的页面才会被重用。
FileBufferPool::allocate_page 中重用了这个页面后，会设置页面的 page_num。 https://github.com/THSS-DB/TDB/blob/328df69ddb1c88dcca0280b678307a50eebd37bc/src/server/storage_engine/buffer/buffer_pool.cpp#L178-L189
由于这个新分配的页面其实是 B+ 树索引文件的 header frame，此时调用 allocated_frame->clear_page(); 实际上将内存中的 header frame 清零了，于是下一行中 page_num 就被设成了 -1。

由于 #19 已经修复了这个问题，把相关的 fix code 合并到 Lab2 的实现中应该能修复这个 bug。

ycycse commented 3 months ago

明白了，Lab2 测试codebase是在这个pr之前的，那看来最新的commit里不会有这个问题

THSS-DB / TDB