[SERVER-62650] RecordStore RecordId initialization can deadlock transactions with cache eviction Created: 14/Jan/22 Updated: 29/Oct/23 Resolved: 04/Feb/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 5.2.0, 5.1.2, 5.0.6 |
| Fix Version/s: | 5.3.0, 5.2.1, 5.0.7 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Louis Williams |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Backport Requested: |
v5.2, v5.0, v4.4
|
||||||||||||||||||||||||||||
| Sprint: | Execution Team 2022-02-07, Execution Team 2022-02-21 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Linked BF Score: | 155 | ||||||||||||||||||||||||||||
| Description |
|
There is a bug with our RecordId initialization that is more generally described by SERVER-61116. As a consequence, very large multi-document transactions that consume most of cache can deadlock. In practice, this has to be the first transaction to write to a given collection. We create a new WT_SESSION to call largest_key() to lazily initialize the highest RecordId for a collection (as of We should use an "operation_timeout_ms" here, as we did in |
| Comments |
| Comment by Githook User [ 23/Mar/22 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: (cherry picked from commit 14b9051a791865503f3b101a62c0903f5c15a4a8) |
| Comment by Githook User [ 08/Feb/22 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: (cherry picked from commit 14b9051a791865503f3b101a62c0903f5c15a4a8) |
| Comment by Githook User [ 04/Feb/22 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |
| Comment by Githook User [ 02/Feb/22 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: Revert " This reverts commit 6d509615d2d6ef7af38e1b982b6272a54e9b591c. |
| Comment by Githook User [ 01/Feb/22 ] |
|
Author: {'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}Message: |
| Comment by Louis Williams [ 24/Jan/22 ] |
|
Actually, the more I think about it, |
| Comment by Louis Williams [ 24/Jan/22 ] |
|
Since this is a problem in a single-transaction environment with a small dirty cache, if we choose to throw a WriteConflictException in this scenario, the results are going to look very similar to Instead of a write conflict, we should return the same error that we return in One note: it's not clear that we can safely backport |