[SERVER-38050] The range deleter doesn't validate it is still operating on the same collection after the deletion loop Created: 09/Nov/18 Updated: 29/Oct/23 Resolved: 11/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.6.8, 4.0.4 |
| Fix Version/s: | 3.6.10, 4.0.6, 4.1.7 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Blake Oler |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||
| Sprint: | Sharding 2018-12-17 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 48 | ||||||||
| Description |
|
After the first collection lock acquisition, the CollectionRangeDeleter's asynchronous thread validates that it is operating on the same collection it was scheduled with. However, later on it drops the collection lock in order to wait for majority replication/range deleter throttling and when it reacquires it back after the blocking wait completes, it doesn't re-check whether the collection is still the same and proceeds to directly modify the metadata manager state which might be for a completely different collection now. |
| Comments |
| Comment by Githook User [ 31/Dec/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'email': 'blake.oler@mongodb.com', 'name': 'Blake Oler'}Message: (cherry picked from commit cee9c4deed8bbf0c612b465be4625d5d0775d204) |
| Comment by Githook User [ 31/Dec/18 ] |
|
Author: {'username': 'BlakeIsBlake', 'email': 'blake.oler@mongodb.com', 'name': 'Blake Oler'}Message: (cherry picked from commit cee9c4deed8bbf0c612b465be4625d5d0775d204) |
| Comment by Githook User [ 11/Dec/18 ] |
|
Author: {'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}Message: |