[SERVER-34351] Fix intermittent alter() failures when upgrading unique indexes. Created: 06/Apr/18 Updated: 06/Dec/22 Resolved: 13/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Sulabh Mahajan | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Sprint: | Storage Non-NYC 2018-04-23 |
| Participants: |
| Description |
|
Unique index upgrade requires the app_metadata stored for the index's WT table to be updated using the alter() command. For a successful execution, alter() requires an exclusive access to the underlying file, otherwise it fails with an EBUSY error. This exclusive access is not granted if there are cursors opened on the file. Our current implementation fails intermittently when other operations on the index race with the index upgrade process. This ticket tracks the work needed to implement an alter() invocation that deterministically gets this exclusive access and doesn't fail intermittently with an EBUSY error. |
| Comments |
| Comment by Sulabh Mahajan [ 13/Apr/18 ] |
|
Closing this ticket because we decided to follow a different approach with how alter() is done. |