[SERVER-35828] Check the readSource in dropCollection Created: 26/Jun/18 Updated: 24/Jan/19 Resolved: 24/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Xiangyu Yao (Inactive) | Assignee: | Xiangyu Yao (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Storage NYC 2019-01-28 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 45 | ||||||||||||
| Description |
|
In BF-9590, we could enter dropCollection() with kMajorityCommitted ReadSource since it's set previously by another command which used the same RecoveryUnit. Then, we read the on-disk index catalog with majorityCommitted timestamp and compare it with the in-memory one. If an index creation was just done after the majority committed point, the in-memory and the on-disk index catalog did not match. I think we should assert that DropCollection() is performed with kUnset/kNoTimestamp ReadSource, or at least be aware that DropCollection() can be performed with other ReadSources. It would be useful to prevent bugs that arise from misusing the storage layer that are difficult and racy to diagnose. Potential fixes: |
| Comments |
| Comment by Xiangyu Yao (Inactive) [ 24/Jan/19 ] |
|
The invariant failed (BF-11843) due to the use of ConfigSvrDropCollectionCommand, indicating that |
| Comment by Eric Milkie [ 16/Jan/19 ] |
|
Reverted to due to build failures. |
| Comment by Githook User [ 16/Jan/19 ] |
|
Author: {'username': 'milkie', 'email': 'milkie@10gen.com', 'name': 'Eric Milkie'}Message: Revert " This reverts commit 29efd5d05db9caab8c8812a83b6692e2e29b5f39. |
| Comment by Githook User [ 14/Jan/19 ] |
|
Author: {'username': 'xy24', 'email': 'xiangyu.yao@mongodb.com', 'name': 'Xiangyu Yao'}Message: |