Issue Summary

In the checkpoint code for the history store (HS), there is concern regarding the handling of the dhandle returned by _wt_session_get_dhandle. Specifically, if the function returns 0 (success) but the dhandle is not opened (i.e., F_ISSET(hs_dhandle, WT_DHANDLE_OPEN) is false), this would indicate a serious underlying issue. Additionally, the code currently loses the return value from the first WT_WITH_DHANDLE call, potentially missing errors from _wt_checkpoint_file.

Context

• The checkpoint code retrieves the HS dhandle and checks if it is opened:

  WT_ERR_ERROR_OK(__wt_session_get_dhandle(session, WT_HS_URI, NULL, NULL, 0), ENOENT, false);
  hs_dhandle = session->dhandle;
  if (F_ISSET(hs_dhandle, WT_DHANDLE_OPEN)) {
      ...
  }
  

• Discussion clarified that if __wt_session_get_dhandle returns 0, the dhandle must be open, as a read lock is held preventing closure.
• The code segment:

  WT_WITH_DHANDLE(session, hs_dhandle, ret = __wt_checkpoint_file(session, cfg));
  if (hs_dhandle_shared != NULL)
      WT_WITH_DHANDLE(session, hs_dhandle_shared, ret = __wt_checkpoint_file(session, cfg));
  

  Currently, the return value from the first WT_WITH_DHANDLE call is overwritten and not checked, which could lead to missed errors.

Proposed Solution

• Ensure that the return value from each WT_WITH_DHANDLE call is preserved and checked, so errors from __wt_checkpoint_file are not lost.
• Consider adding assertions or error handling to verify that if __wt_session_get_dhandle returns 0, the dhandle is indeed open.

This ticket was generated by AI from a Slack thread.