BugZero found this defect 2410 days ago.
All data on this page is proprietary to BugZero or gathered from public sources
No fixed releases provided.
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.
charlie.swanson commented on Fri, 21 Jul 2017 16:08:06 +0000: 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: local variable n in serializeReply, which uses a 'long long'. SingleWriteResult (generated by the IDL file), which uses a 'long', which it looks like IDL translates to an int64_t. The information on the SingleWriteResult looks to be filled out by requesting the number of deleted things from the DeleteStage, which does so by consulting it's DeleteStats, which uses a size_t On mongos: BatchWriteOp, which uses a 'int' BatchCommandResponse, which uses a 'long long' 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. rstam commented on Fri, 21 Jul 2017 14:38:44 +0000: It would be helpful to users to know exactly which version this was fixed in. firstname.lastname@example.org commented on Fri, 21 Jul 2017 14:35:33 +0000: Since this is already fixed in 3.4 and is simply a reporting error, we have no plans to fix this in 3.2.
Understand the cost to your business and how BugZero can help you reduce those costs.
Login to read and write comments.