[SERVER-30232] delete command on mongos can return a negative count of deleted documents Created: 19/Jul/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 3.2.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Robert Stam | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | Create a collection named "test" with 2,147,483,648 documents. That's one more than the largest possible positive number that can be represented with a 32 bit signed integer. Run the following command:
The expected result is:
The actual result is:
|
||||||||
| Participants: | |||||||||
| Description |
|
When a very large number of documents matches the query the count of deleted documents can overflow and become negative. I have reproduced this with 3.2.10. It works correctly in 3.4.6. This ticket might be a duplicate, but I couldn't find a ticket for this. |
| Comments |
| Comment by Charlie Swanson [ 21/Jul/17 ] |
|
I'm actually going to re-open this. While attempting to find which version this was fixed in, I realized there are actually many types involved in tracking how many deletes occurred on master, including: On mongod:
On mongos:
So it looks like all the types on mongod are ok (though the size_t should probably be replaced with a uint64_t, just to be sure). However, this is probably still a problem on mongos, and may still be a problem for update (or insert?). rstam if you're concerned with just a single mongod, it looks like this was likely fixed by |
| Comment by Robert Stam [ 21/Jul/17 ] |
|
It would be helpful to users to know exactly which version this was fixed in. |
| Comment by Ian Whalen (Inactive) [ 21/Jul/17 ] |
|
Since this is already fixed in 3.4 and is simply a reporting error, we have no plans to fix this in 3.2. |