[SERVER-58219] Investigate ViewCatalog::reload() lock acquisition Created: 02/Jul/21 Updated: 16/Aug/21 Resolved: 16/Aug/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Dan Larkin-York |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Execution Team 2021-08-23 | ||||||||
| Participants: | |||||||||
| Description |
|
A new invariant was added where operations that are holding open an oplog hole cannot try to acquire subsequent locks. To temporarily circumvent this check, a new RAII-style class called IgnoreLockConstraintsOnTimestampedTxn was added to opt-out of the invariant. There's a TODO in the codebase for this ticket. See The goal of this ticket should be to determine whether acquiring the lock can actually block in practice (perhaps another thread acquires a stronger lock).
|
| Comments |
| Comment by Githook User [ 16/Aug/21 ] |
|
Author: {'name': 'Dan Larkin-York', 'email': 'dan.larkin-york@mongodb.com', 'username': 'dhly-etc'}Message: |