Splitting work off from WT-7853 to make the intent of the change a bit more specific and allow for deliberate back-porting of one half and not the other half or vice versa. We would like to be able to panic in reconciliation if we fail to insert content to the history store in all cases, and possible in further code paths in reconciliation after we've done history store inserts.
The actual time we panic and what scenarios we panic in should be clearly defined on this ticket and implemented as part of it.
Currently I have two suggestions:
- Panic after failing to do any history store insertion.
- Set a flag on reconciliation that will panic if it fails during the history store insertion or after it, e.g. in the page split code.
Suggestion 1 implies that it's okay to fail later in reconciliation and not panic as we've successfully done all of the history work, which should avoid and uncertainty about whether we've flagged WT_UPDATE_DS or WT_UPDATE_HS successfully.
Suggestion 2 is more of a catch all failure suggestion in that if we did do any history store work its not okay to fail the reconciliation ever subsequently.
- causes
-
WT-9268 Delay deletion of the history store record to reconciliation
- Closed
- depends on
-
WT-8221 Compare write generation number before performing RTS
- Closed
-
WT-8270 Updating the time window clear obsolete stage of reconciliation to correctly consider global visibility.
- Closed
-
WT-7853 Validate the update chain before we attempt to insert it into the history store
- Closed
- is depended on by
-
WT-8414 Assertion failure in wt_rec_upd_select upd_select->upd == NULL || !F_ISSET(upd_select->upd, WT_UPDATE_HS)
- Closed
-
WT-8105 Remove the hs_cursor insert success flag once panic on failure is implemented
- Closed