[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:
Related
related to CSHARP-2017 DeleteMany().DeletedCount overflow Closed
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:

db.runCommand({ delete : "test", deletes : [ { q : {}, limit : 0 } ] })

The expected result is:

{ "ok" : 1, "n" : 2147483648 }

The actual result is:

{ "ok" : 1, "n" :  -2147483648 }

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 SERVER-23128, which deleted the offending WriteOpStats which was storing an int.

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.

Generated at Thu Feb 08 04:23:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.