-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 5.0.0, 6.0.0, 7.0.0, 8.0.0-rc0, 7.3.0
-
Component/s: None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v8.0
-
CAR Team 2024-06-10, CAR Team 2024-06-24, CAR Team 2024-07-08
-
200
-
2
What's the problem?
The real issue is that we are clearing the filtering metadata without actually holding the recoverable critical section. This mostly happens in DDL coordinators: it could happen that the phase that releases the critical section is retried but the critical section was already released. In this case, we shouldn't clear the filtering metadata (e.g. here) because it was done before.
Note that this is not just a problem of that command but potentially it affects other DDL operations. Any DDL that has a phase that 1) clears the filtering metadata and 2) releases the critical section might be affected as well.
Solutions
A potential solution would be to clear the filtering metadata on primaries and secondaries when releasing the critical section. Right now we are only doing on secondaries.
- causes
-
SERVER-92498 server_write_concern_metrics_sharding.js can fail due to sharding catalog cache writes
- Closed
- has to be done before
-
SERVER-90861 Tighten the conditions for clearing the collection filtering metadata
- Backlog
- is related to
-
SERVER-79600 Simplify the usage of the Recoverable Critical Section, clearing the filtering metadata in all nodes when blocking both reads and writes
- Backlog
- related to
-
SERVER-90861 Tighten the conditions for clearing the collection filtering metadata
- Backlog