[SERVER-38477] Index build lock acquisitions should be interruptible Created: 07/Dec/18 Updated: 29/Oct/23 Resolved: 31/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.14 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Eric Milkie |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | prepare_interruptibility, uninterruptibleLockGuardRemoval | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Storage NYC 2018-12-31, Storage NYC 2019-01-14, Storage NYC 2019-01-28, Storage NYC 2019-02-11, Storage NYC 2019-03-25, Storage NYC 2019-04-08, Storage NYC 2019-04-22, Storage NYC 2019-05-06, Storage NYC 2019-05-20, Execution Team 2019-06-03 | ||||||||
| Participants: | |||||||||
| Story Points: | 13 | ||||||||
| Description |
|
Index build avoids interruptions in several places, especially for background index build. They will conflict with prepared transactions on stepdown and shutdown. We can either make index build interruptible, or use IX or IS locks instead of X or S locks. Here's a list of all occurrences of UninterruptibleLockGuard for index build. |
| Comments |
| Comment by Eric Milkie [ 31/May/19 ] |
|
I eliminated the uninterruptible guards for the create index command, but the guard that protects the cleanup of the catalog on index build failure was difficult to remove and I'm not sure it's necessary. Will follow up with the replication team for that consideration. |
| Comment by Githook User [ 31/May/19 ] |
|
Author: {'name': 'Eric Milkie', 'email': 'milkie@10gen.com', 'username': 'milkie'}Message: |
| Comment by Siyuan Zhou [ 27/Dec/18 ] |
|
Agreed. "multi_index_block_impl.cpp" doesn't conflict with prepared transactions. |
| Comment by Eric Milkie [ 27/Dec/18 ] |
|
src/mongo/db/catalog/multi_index_block_impl.cpp:156 is only there to protect locks on the local database. I wonder if we don't have to remove that one. |