-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Checkpoints
-
None
-
Storage Engines - Persistence
-
SE Persistence - 2026-03-27, SE Persistence - 2026-04-10
-
2
Currently, __checkpoint_db_internal parses the config string many times in different calls, and uses many local variables to store information extracted from the config. This introduces extra lines of code and complexity that isn't needed. here for example cfg is parsed multiple times:
/* Avoid doing work if possible. */ WT_RET(__checkpoint_can_skip(session, cfg, &use_timestamp, &can_skip)); if (can_skip) { WT_STAT_CONN_INCR(session, checkpoint_skipped); return (0); } /* Check if this is a named checkpoint. */ WT_RET(__wt_config_gets(session, cfg, "name", &cval)); if (cval.len != 0) { name = cval.str; namelen = cval.len; } else { name = NULL; namelen = 0; } /* * Do a pass over the configuration arguments and figure out what kind of checkpoint this is. */ WT_RET(__checkpoint_apply_operation(session, cfg, NULL));
A config struct should be introduced so that the config string can be parsed once and information can be stored inside the struct. This can then be used later whenever information from the config is needed.
Definition of done:
- A cfg struct is defined capturing all config-derived variables.
- The struct is populated once at the start of __checkpoint_db_internal and passed down where needed.
- related to
-
WT-16934 Refactor __checkpoint_db_internal to use cfg struct
-
- Closed
-