-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
ALL
-
-
CAR Team 2024-09-30
-
0
We've observed this while working on SERVER-87119 to use the collection acquisition logic from the shard role API. I'm not sure why we aren't seeing this with validate today, but what we observed once we swapped the APIs was that validate:
- Saw the fast count for an uncommitted transaction inserting two docs (ex: fast count 5 docs, itcount 3 docs)
- Validate fixes the fast count to how many documents it saw (ex: fast count 3 docs, itcount 3 docs)
- The uncommitted transaction commits two docs (ex: fast count 3 docs, itcount 5 docs)
So validate made the fast count incorrect by rolling back the change for the uncommitted transaction.
- is depended on by
-
SERVER-87119 Introduce the collection acquisition logic from the shard-role api into the validate command
- Backlog
- is fixed by
-
SERVER-94992 Shard Role acquisitions update read source on secondaries even if they are "writing"
- Closed
- is related to
-
SERVER-95752 Yielding locks with uncommitted prepared transactions can cause validate to update the fast count incorrectly
- Backlog