-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Execution
-
ALL
As seen in SERVER-94825, uncommitted fast count updates leak out to other concurrent operations. Initially, this was harmless as validation obtains an exclusive lock on the collection, so it should be serialized with CRUD operations. However, uncommitted prepared transactions yield locks when a node steps down. This allows validation to run and incorrectly adjust the fast count.
Could we make fast count updates ACID-compliant? It doesn't seem right to have validation skip updating fast count if there are uncommitted prepared transactions. It seems like a slippery slope if there are more ways we can get into this scenario.
- is depended on by
-
SERVER-95487 Collection validation does not update count/size if collection is empty
- Blocked
- is related to
-
SERVER-44837 Collection validation can cause inaccurate fast count when run against a node with a prepared transaction
- Closed
- related to
-
SERVER-94825 Uncommitted fast count updates leak out to other operations
- Closed