-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Block Manager
-
None
-
Storage Engines, Storage Engines - Persistence
-
0.004
-
SE Persistence backlog
-
None
Similarly to WT-18036, we want more signal whenever we hit this condition. This should not affect production builds.
We currently have this code:
/* Validate the size of the btree. */
if (F_ISSET(btree, WT_BTREE_DISAGGREGATED) && ckpt->size != vs->total_block_size) {
/*
* FIXME-WT-16660: We are seeing mismatches due to nuanced reconciliation issues,
* where bytes_total increments happen before the reconciliation panic boundary,
* leaving us in an inconsistent state if reconciliation fails after the increment
* but before completion. Re-enable this check once this is resolved.
*/
if (false)
WT_ERR_MSG(session, WT_ERROR,
"checkpoint size %" PRIu64 " does not match accumulated block size %" PRIu64,
ckpt->size, vs->total_block_size);
}
We should execute the WT_ERR_MSG code in diagnostic builds.
- has to be done before
-
WT-18038 Enable the check of WT-18037 in production
-
- Open
-
- is related to
-
WT-16660 bytes_total increment not protected by reconciliation panic boundary
-
- Closed
-
-
WT-18036 Make the underflow warning a WT_ASSERT when decreasing block size
-
- Closed
-
- related to
-
WT-18039 Enable the check of WT-18036 in production
-
- Open
-