Details
-
Task
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
-
None
-
None
-
Fully Compatible
-
Sharding EMEA 2022-11-14, Sharding EMEA 2022-11-28, Sharding EMEA 2022-12-12, Sharding EMEA 2022-12-26, Sharding EMEA 2023-01-09, Sharding EMEA 2023-01-23, Sharding EMEA 2023-02-06, Sharding EMEA 2023-02-20, Sharding EMEA 2023-03-06
-
153
Description
DropCollectionCoordinator is currently deleting the collection metadata and data without explicitly blocking any user write operation on the namespace. While this behaviour is aligned with the isolation guarantees offered by the DDL, it may lead to an inconsistent sequence of events in the primary shard oplog.
The addition of a RecoverableCriticalSection protecting the execution of the whole kDropCollection phase could be a way to solve this problem.
Attachments
Issue Links
- causes
-
SERVER-74348 New parameter to support views on the release of the recoverable critical section was wrongly placed
-
- Closed
-
- is depended on by
-
SERVER-68930 Store placement changes into config.placementHistory when a dropCollection() command gets committed on the config server
-
- Closed
-
-
SERVER-70922 Modify drop collection to clear the sharding index catalog
-
- Closed
-
- related to
-
SERVER-74300 Investigation: understand why the acquisition of the critical section doesn't have waitForLock:true
-
- Open
-