-
Type: Bug
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: 4.2.1, 4.3.2
-
Component/s: Storage
-
None
-
ALL
-
-
Execution Team 2019-12-30, Execution Team 2020-05-04, Execution Team 2020-05-18, Execution Team 2020-06-01
-
0
When we run collection validation we will update the "fast count" value for a collection, based on how many documents we observe when scanning the collection. If we run validation against a node that currently has an open, prepared transaction that has done operations against the collection we are validating, we may incorrectly update the fast count value since validation cannot observe the effects of the uncommitted transaction. For example, if we have done 10 inserts against collection A, a prepared transaction has done 10 inserts against collection A, and then we run validate against A, we will update the fast count to 10, since we do not see the effects of the transaction yet. If the transaction later aborts, though, we will decrement the fast count by 10, leaving us with a fast count of 0 indefinitely, even though there are 10 documents in the collection.
- related to
-
SERVER-95752 Yielding locks with uncommitted prepared transactions can cause validate to update the fast count incorrectly
- Backlog
-
SERVER-41888 Shutting down with prepared transaction can invariant during collection validation
- Closed
-
SERVER-48981 Implement local isolation for fastcount for Biggie RecordStore
- Closed