[SERVER-53817] Remove check for shouldConflictWithSecondaryBatchApplication() in isCollectionLockedForMode() Created: 14/Jan/21 Updated: 29/Oct/23 Resolved: 28/Jul/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Henrik Edin | Assignee: | Gregory Noma |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | auto-reverted, techdebt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution NAMR Team 2023-08-07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 169 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
isCollectionLockedForMode() has a special case where it always returns true if shouldConflictWithSecondaryBatchApplication returns false: While we might not need to hold locks in this special mode it causes seemingly confusing behavior where the locker reports that locks are held. We have invariants throughout the codebase that checks if Collections are locked in certain modes. Here are a few that would start firing in certain conditions if the shouldConflictWithSecondaryBatchApplication check is removed from isCollectionLockedForMode |
| Comments |
| Comment by Githook User [ 28/Jul/23 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: |
| Comment by xgen-buildbaron-user [ 28/Jul/23 ] |
|
Ticket re-opened due to revert. change_streams_multitenant_passthrough began a consistent failure of jstests/change_streams/pipeline_style_updates.js |
| Comment by Githook User [ 28/Jul/23 ] |
|
Author: {'name': 'auto-revert-processor', 'email': 'dev-prod-dag@mongodb.com', 'username': ''}Message: Revert " This reverts commit 7361e4e5bf9758705fb46c2cc022defa22c4042f. |
| Comment by Githook User [ 27/Jul/23 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: |
| Comment by Jordi Olivares Provencio [ 25/Jul/23 ] |
|
We set the flag for shouldConflictWithSecondaryBatchApplication to false on multi-document transactions as well. I didn't know this ticket existed and filed |
| Comment by Dianna Hohensee (Inactive) [ 05/Feb/21 ] |
|
Copying this here, as it is enlightening about why this lock bypass exists: "Apparently, for secondary oplog application, the writer threads expect the main applier thread to hold locks for them. The main applier thread runs X lock operations serially, so no other writers are active in the system. Therefore, isCollectionLockedForMode returns true if shouldConflictWithSecondaryBatchApplication==false as a signal that is what is happening." |