-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
CAR Team 2026-03-16
-
None
-
None
-
None
-
None
-
None
-
None
-
None
DDL locks are currently used to serialize DDLs on the same namespace on sharded clusters.
Considering that on replica sets there are some DDLs such as collMod that acquire/release/re-acquire the collection lock during their execution, it would be useful to use the DDL locks also on replica sets.
Benefits:
- Prevent concurrent DDLs from sneaking in
- Check preconditions before acquiring db/collection locks in strong modes in order to avoid unnecessary lock contention and have the guarantee that preconditions will hold during the whole duration of the operation
NB: if some DDL at replica set level is not atomic, this would still not prevent DDLs from getting half-committed upon stepdown/crash.
- derives
-
SERVER-120983 Move the DDLLockManager to the shard_role/ddl folder
-
- Closed
-
- is depended on by
-
SERVER-90862 Creating a collection or a view should fail if a bucket namespace exists without its view
-
- Blocked
-
-
SERVER-92271 Renaming a collection or a view should fail if a buckets namespace exists
-
- Blocked
-
-
SERVER-105925 Ensure collmod works correctly with concurrent timeseries collection drop and re-create
-
- Blocked
-
-
SERVER-95760 $out: acquire locks for target namespaces when outputting to timeseries
-
- Blocked
-
- is related to
-
SERVER-116090 Drop may be skipped if it interleaves with viewless timeseries upgrade/downgrade (replica set)
-
- Closed
-
-
SERVER-99646 Unify collection locks for the timeseries view and buckets namespaces
-
- Closed
-
- related to
-
SERVER-121067 Tests should not depend on the locking behavior of dropCollection
-
- In Code Review
-