-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
ALL
-
Storage Execution 2026-04-13
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In the process of working on SERVER-109829 we forced as many collections to go throguh a durable recovery from disk as possible in order to catch use-after-free bugs during testing.
However, we instead discovered that the oplog's visibility thread is controlled by the RecordStore whenever we have to instantiate one from the KVEngine. This results in a clash whenever the collection has to be recovered from disk in the presence of a DDL on the oplog.
As a result, multiple queries could be simultaneously starting/stopping the oplog visibility thread if they request the oplog and durable recovery is necessary due to DDLs. Making each of those requests start/stop the oplog visibility thread.
Today I don't believe this is a problem since almost no DDLs can occur on the oplog therefore making this problem effectively impossible to hit in practice. However, it is an additional exception that has to be made just for the oplog at the catalog level which is undesireable.
- is related to
-
SERVER-119964 Collection catalog race condition shuts down oplog visibility thread after rollback
-
- Closed
-
-
SERVER-109829 Provide test/debug option for Catalog to always return deep copy
-
- In Code Review
-