[SERVER-44036] Ensure that we check for existing indexes under a MODE_IX collection lock during createIndexes before taking the MODE_X collection lock Created: 15/Oct/19 Updated: 29/Oct/23 Resolved: 06/Nov/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Catalog, Index Maintenance |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Geert Bosch | Assignee: | Maria van Keulen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Execution Team 2019-11-04, Execution Team 2019-11-18 |
| Participants: |
| Description |
|
Neither the successful and unsuccessful (IndexKeySpecsConflict) cases modify the catalog, so just use MODE_IX collection locks in all cases where an index already exists before we take the MODE_X lock. |
| Comments |
| Comment by Githook User [ 05/Nov/19 ] |
|
Author: {'name': 'Maria van Keulen', 'username': 'mvankeulen94', 'email': 'maria.vankeulen@mongodb.com'}Message: |
| Comment by Maria van Keulen [ 01/Nov/19 ] |
|
We accept the case where createIndexes inside a transaction hangs on an in-progress index build outside of a transaction. We do not care about the reverse case since we only allow createIndexes inside of a transaction if the index already exists or on a collection that was created inside the same transaction. |
| Comment by Maria van Keulen [ 01/Nov/19 ] |
|
As an update, the function IndexCatalogImpl::prepareSpecForCreate, which is called before we take the MODE_X collection lock during createIndexes, does handle all success/error cases of an index already existing with conflicting specs. |
| Comment by Maria van Keulen [ 30/Oct/19 ] |
|
I have confirmed with geert.bosch that for this ticket we do not care about the cases where we encounter index build conflicts after taking the exclusive collection lock. Since we have an existing framework for checking for existing indexes before taking this lock (see my above comment) the work for this ticket should be to verify that this framework handles all possible existing index scenarios. |
| Comment by Maria van Keulen [ 30/Oct/19 ] |
|
We presently check for existing indexes under a Collection IX lock before taking the exclusive collection lock during index builds. Two other cases of interest are the success case and the failure case that occur after we have the Collection X lock. IIUC, we cannot guarantee that we avoid conflicts with existing builds until after we hold the Collection X lock. As a result, I don't think we can refactor the aforementioned success/failure cases to occur exclusively outside of the Collection X lock. We can determine if it's possible to release the Collection X lock earlier once we have encountered the index conflicts. |