-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: 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
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.
- 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
- is duplicated by
-
SERVER-61933 Interleaved operations during sharded collection drop violate change stream guarantees
- Closed
- related to
-
SERVER-74300 Investigation: understand why the acquisition of the critical section doesn't have waitForLock:true
- Needs Scheduling
-
SERVER-61933 Interleaved operations during sharded collection drop violate change stream guarantees
- Closed