[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: SERVER-44036 Test that existing index creation takes intent locks
Branch: master
https://github.com/mongodb/mongo/commit/da5cd52964f1e5551360ed21e84bcf8ab129ba47

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.
The remaining work for this ticket is to add a test that createIndexes on an index that already exists as of the beginning of the createIndexes command only needs an IX lock.

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.
However, as of SERVER-40926/SERVER-40927, createIndexes on an index that is already in progress will hang until the in-progress build finishes.
This might be adverse behavior for transactions.

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.

Generated at Thu Feb 08 05:04:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.