[SERVER-32820] Support new unique index format during secondary apply Created: 22/Jan/18 Updated: 22/Feb/18 Resolved: 22/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Alexander Gorrod | Assignee: | Neha Khatri |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Storage 2018-02-12, Storage 2018-02-26 | ||||||||
| Participants: | |||||||||
| Description |
|
The new unique index format needs to avoid doing an insert/remove pair of operations on the unique index table when in dupsAllowed mode - since applyOps shares a set of work across multiple threads unique index constraints can be temporarily violated. The violation will be resolved at each batch completion boundary. We will be able to identify places in the code that require updates by looking for code that handles the dupsAllowed flag. We should use the test case developed in |
| Comments |
| Comment by Neha Khatri [ 22/Feb/18 ] |
|
This work is done along with |