[SERVER-56002] listIndexes can read partial state from renameCollection Created: 09/Apr/21 Updated: 29/Oct/23 Resolved: 20/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0, 5.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Mihai Andrei | Assignee: | Henrik Edin |
| 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.0
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2021-05-17, Execution Team 2021-05-31 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 158 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Essentially, the issue appears to be that listIndexes can read from the DurableCatalog in the middle of a concurrent collection rename (after the original target was dropped, but before the source collection is renamed). This looks to be possible because the listIndexes can read from the DurableCatalog using the same catalogId that the collection rename removes from the DurableCatalog. Some ideas for how to fix this include making listIndexes no longer lock free as well as reimplementing listIndexes to use the IndexCatalog instead of the DurableCatalog. |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 24/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: All updates to the metadata needs to happen through the Collection, moved interfaces from the DurableCatalog to the Collection. Multikey handle is special as it needs to happen without exclusive access to the Collection. Implemented isolation for the Collection metadata when multikey is changed. It handles multi-doc transactions and is only commited to the Collection instance after the write to the durable catalog successfully commits. listCollections and listIndexes can now safetly read the metadata cache without needing to read from the durable catalog making them safe to do without Collection level locks. (cherry picked from commit 11de948b0c50df7d12de09ae0f01e791fc5d70d7) |
| Comment by Githook User [ 24/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: (cherry picked from commit 15e97c021b4e1feba110f31a563076980794d0a5) |
| Comment by Githook User [ 20/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: All updates to the metadata needs to happen through the Collection, moved interfaces from the DurableCatalog to the Collection. Multikey handle is special as it needs to happen without exclusive access to the Collection. Implemented isolation for the Collection metadata when multikey is changed. It handles multi-doc transactions and is only commited to the Collection instance after the write to the durable catalog successfully commits. listCollections and listIndexes can now safetly read the metadata cache without needing to read from the durable catalog making them safe to do without Collection level locks. |
| Comment by Githook User [ 20/May/21 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: |
| Comment by James Wahlin [ 06/May/21 ] |
|
Requesting 4.9 backport as we had a BF on that branch that we believe is caused by this issue. |