Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
None
-
None
-
Fully Compatible
-
ALL
-
50
Description
When enableMajorityReadConcern=false it set dropping collections is not using the ident reaper and is dropped in a commit handler for the storage transaction dropping the collection.
https://github.com/mongodb/mongo/blob/0ce2fa7273aa7f4c7170c1bba3944efe46b4f043/src/mongo/db/storage/storage_util.cpp#L111
SERVER-53535 added proper isolation for collection drops and they are now committed into the catalog as the last commit handler that executes on the recovery unit. This causes the code that checks if we need to delete an empty directory to run too early as the collection hasn't been removed from the catalog yet.
https://github.com/mongodb/mongo/blob/0ce2fa7273aa7f4c7170c1bba3944efe46b4f043/src/mongo/db/storage/storage_util.cpp#L54-L58
This code can have its RecoveryUnit moved from one OperationContext to another so it is not safe to capture the OperationContext in the lambda for the commit handler. That makes it not possible to check if the last Collection in the catalog is about to be dropped by looking at UncommittedCatalogUpdates for this OperationContext.
Another possible solution would be to allow for registering Callbacks that run after the special RecoveryUnit Change that is responsible for catalog visibility. However that comes with its own issues and such Callbacks would have to adhere to their own set of special rules (no further modification of writable collections)
Attachments
Issue Links
- related to
-
SERVER-53535 Rename with dropTarget must be done atomically in the catalog to prevent a lock free reader to observe intermediate invalid state
-
- Closed
-