[SERVER-73395] Query on temporary resharding collection has plan cache entry after resharding completes Created: 27/Jan/23 Updated: 06/Feb/24 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Sergi Mateo Bellido |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||||||
| Sprint: | Sharding EMEA 2023-02-20, Sharding EMEA 2023-03-06, Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03, Sharding EMEA 2023-04-17, Sharding EMEA 2023-05-01, Sharding EMEA 2023-05-15, Sharding EMEA 2023-05-29, Sharding EMEA 2023-06-12, Sharding EMEA 2023-06-26, Sharding EMEA 2023-07-10, Sharding EMEA 2023-07-24, Sharding EMEA 2023-08-07, Sharding EMEA 2023-08-21, Sharding EMEA 2023-09-04, Sharding EMEA 2023-09-18, Sharding EMEA 2023-10-02, Sharding EMEA 2023-10-16, Sharding EMEA 2023-10-30, CAR Team 2023-11-13, CAR Team 2023-11-27, CAR Team 2023-12-11, CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22, CAR Team 2024-02-05, CAR Team 2024-02-19 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Context: Many commits ago, a check was added to skip running findOne() on empty collections until non-blocking sort was enabled for clustered collections. According to the TODO, the check can now be removed from the resharding::data_copy::findDocWithHighestInsertedId. Although the check may actually be an optimization we wish to keep, we should investigate the side effects in case other things in resharding change and it becomes an issue in the future. Reproduction:
Question: Is it expected for the findOne() on the temporary resharding collection to remain as a plan cache entry? Hypothesis: The findOne() run on the temporary resharding collection and when the collection is renamed, collIIsDropped is false by default, and _cleanupBeforeInstallingNewCollectionMetadata does not clean up the plan cache entry ( |
| Comments |
| Comment by Sergi Mateo Bellido [ 01/Mar/23 ] |
|
RenameCollection and dropCollection are explicitly calling to clearFilteringMetadataForDroppedCollection, we should do the same for reshardCollection. |
| Comment by Sergi Mateo Bellido [ 01/Mar/23 ] |
|
I believe that the real issue here is that for the temporary namespace we are not calling to clearFilteringMetadataForDroppedCollection but just to clearFilteringMetadata. This new function was introduced in |
| Comment by Haley Connelly [ 27/Jan/23 ] |
|
If we decide to keep the check where we return early if a collection is empty, this is a non-issue in todays code. cc max.hirschhorn@mongodb.com since this is resharding related |