[SERVER-53697] Directory per DB broken when enableMajorityReadConcern=false is set Created: 11/Jan/21 Updated: 29/Oct/23 Resolved: 12/Jan/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Henrik Edin | Assignee: | Henrik Edin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 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.
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) |
| Comments |
| Comment by Githook User [ 12/Jan/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: The callback with the logic is running before the collection is removed from the catalog. Blindly attempt to delete the empty directory in this case. |