[SERVER-20063] WiredTiger collection size cache can be inaccurate Created: 20/Aug/15  Updated: 06/Dec/22  Resolved: 15/Apr/19

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Martin Bligh Assignee: Backlog - Storage Execution Team
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File negativeSize.js    
Issue Links:
Duplicate
duplicates SERVER-24266 Large discrepancy in SizeStorer after... Backlog
is duplicated by SERVER-23124 db.collection.count() returns -1 Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

The code to handle "negative" sizes seems to have several issues.

1. We can return size of things that aren't committed and possibly nonsensical to users (eg negative values).
2. There's races in things doing fetch then store. Data is lost if someone updates before the store

  if (_numRecords.fetchAndAdd(diff) < 0)
        _numRecords.store(diff);

3. Tradeoffs of not being able to see your own uncommited changes vs everyone else being able to see your uncommited changes - I think we took the wrong path here, and would be better to update on commit. Need to further consider implications.
4. If we update on commit, need to do something about when we cap collections



 Comments   
Comment by Kelsey Schubert [ 16/Mar/16 ]

I've attached a jstest that reproduces some of the behavior described in this ticket.

Generated at Thu Feb 08 03:53:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.