page_num may be -1 when creating index

[ycycse]

当涉及数据过多，索引创建涉及页的驱逐时，我们发现，存在页的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]

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

具体原因是：

• 如果 Lab1 的实现中 evict_all_pages 没有判断 pin_count 就释放了页面（或者使用了实际上不能工作的 ASSERT，见 CMAKE_CXX_FLAGS not correctly set in CMakeLists.txt #18），则 B+ 树索引文件的 header frame（page 0，记录页面分配信息）会被错误释放，如 Potential issue in invocation of FileBufferPool::evict_all_pages() in BplusTreeHandler::sync() #17 中所述。
• LRU Cache 的策略是把被释放的页面放在链表尾，因此直到占满页面池后这个错误释放的页面才会被重用。
• FileBufferPool::allocate_page 中重用了这个页面后，会设置页面的 page_num。
  

  TDB/src/server/storage_engine/buffer/buffer_pool.cpp

  Lines 178 to 189 in 328df69

  	file_header_->allocated_pages++;
  	file_header_->page_count++;
  	byte = page_num / 8;
  	bit = page_num % 8;
  	file_header_->bitmap[byte] |= (1 << bit);
  	hdr_frame_->mark_dirty();
  	allocated_frame->set_file_desc(file_desc_);
  	allocated_frame->access();
  	allocated_frame->clear_page();
  	allocated_frame->set_page_num(file_header_->page_count - 1);

• 由于这个新分配的页面其实是 B+ 树索引文件的 header frame，此时调用 allocated_frame->clear_page(); 实际上将内存中的 header frame 清零了，于是下一行中 page_num 就被设成了 -1。

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

[ycycse]

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