-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Engines, Storage Engines - Foundations
-
None
-
None
-
0
A look at our defined sub-level errors in api_err.py we have:
Error('WT_UNCOMMITTED_DATA', -32008,
"Table has uncommitted data", '''
This sub-level error returns when the table has uncommitted data.'''),
Error('WT_DIRTY_DATA', -32009,
"Table has dirty data", '''
This sub-level error returns when the table has dirty content.'''),
Error('WT_CONFLICT_TABLE_LOCK', -32010,
"Another thread currently holds the table lock", '''
This sub-level error indicates that a concurrent operation is performing
a table operation.'''),
Error('WT_CONFLICT_CHECKPOINT_LOCK', -32011,
"Another thread currently holds the checkpoint lock", '''
This sub-level error indicates that a concurrent operation is performing
a checkpoint.'''),
Error('WT_MODIFY_READ_UNCOMMITTED', -32012,
"Read-uncommitted readers do not support reconstructing a record with modifies", '''
This sub-level error indicates that a reader with uncommitted isolation
is trying to reconstruct a record with modifies. This is not supported.'''),
Error('WT_CONFLICT_LIVE_RESTORE', -32013,
"Conflict performing operation due to an in-progress live restore", '''
This sub-level error indicates that there is a conflict performing the operation
because of a running live restore in the system.'''),
New sub-levels will be added as the codebase grows. Whenever we add a new sub-level error code, we need to manually assign a number to it. We should instead generate this list and alphabetically sort this list.