-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Checkpoints, Cursors
-
None
-
Storage Engines, Storage Engines - Foundations
-
None
-
None
From what I understand, a long-running checkpoint could block the creation of a checkpoint cursor. I believe it should open the last successful checkpoint but after looking at the code, it seems that it will return EBUSY if there is a checkpoint running and this EBUSY is handled and retried internally.
See here and here where we set EBUSY and the internal loop here
What needs to be done:
- Create a test where we open a checkpoint cursor while a checkpoint is running
- Add stats / logs when a checkpoint cursor cannot be opened
- is related to
-
WT-10715 Automatically try previous checkpoints when opening a checkpoint cursor
-
- Open
-