-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: 8.3.0-rc0
-
Component/s: None
-
Catalog and Routing
-
CAR Team 2026-03-30, CAR Team 2026-04-13
-
🟦 Shard Catalog
-
None
-
None
-
None
-
None
-
None
-
None
When we implemented viewless timeseries upgrade/downgrade in SERVER-114505, when acquiring the locks over the view+buckets namespaces, we added a 30s lock timeout and retry loop. This was motivated because some DDLs did not acquire the view+buckets locks in canonical order (increasing ResourceId) so we wanted to preclude deadlocks.
Since SERVER-116090 timeseries DDLs acquire locks for in canonical order like all other operations.
Furthermore, the lock checker (SERVER-99150) is not flagging any lock ordering violation in all of the upgrade/downgrade suites.
Therefore it's safe to remove the retry loop & lock timeout.
- is related to
-
SERVER-116090 Drop may be skipped if it interleaves with viewless timeseries upgrade/downgrade (replica set)
-
- Closed
-
-
SERVER-106990 Make ShardingRecoveryService::acquireRecoverableCriticalSectionBlockWrite support aborting unprepared transactions in between enqueuing lock request for collection X lock and acquiring the lock
-
- Blocked
-
-
SERVER-114505 Basic support for viewless timeseries upgrade/downgrade in replica sets
-
- Closed
-
-
SERVER-114830 Implement viewless timeseries upgrade/downgrade in the shard catalog
-
- Closed
-
-
SERVER-99646 Unify collection locks for the timeseries view and buckets namespaces
-
- Closed
-