Any operation that requires exclusive access to an object (currently that list includes verify, salvage/rollback-to-stable, and upgrade), will first attempt to close all of the existing open handles and then open an exclusive handle on the object.
If there are dirty updates in the cache for the object, as part of closing all open handles we call __wt_txn_checkpoint(), which hits this code:
and returns EBUSY, and the operation fails.
This is easy to reproduce with test_prepare_hs03, and haribabu.kommi believes he's seen it where MongoDB reports EBUSY returns from collection validation. (As MongoDB surfaces the collection validation operation through its API, it makes sense a MongoDB application could see this failure.)
- force a database-wide checkpoint as part of an operation requiring exclusive access to the object (if EBUSY is returned from our attempt to close all open handles, we could do a database-wide checkpoint and then try again).
- document this away, although it's messy to do that because as soon as a checkpoint completes, then the failing operation can proceed, so it's a case of repeatedly trying until the operation succeeds.
- haribabu.kommi thinks that this code may be too pessimistic, and that maybe we can relax the constraints, that history-store means the check may no longer be required.
Anyway, can you folks weigh in on this one and give us some guidance?