[SERVER-48916] Update plan cache IndexabilityDiscriminator when IndexCatalogEntry is updated Created: 17/Jun/20 Updated: 03/Aug/20 Resolved: 17/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 3.6.18, 4.0.19 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Arun Banala | Assignee: | Arun Banala |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Query 2020-06-29 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
When the collMod operation updates the TTL of an index, we delete the existing IndexCatalogEntry and create a new one with the updated specifications. The IndexCatalogEntry also owns a CollatorInterface object. The same CollatorInterface object is being used in the plan cache here. So after the IndexCatalogEntry got deleted and re-created, the pointer to collator in CompositeIndexabilityDiscriminator is pointing to a freed memory. This seems to have been fixed on 4.2, but still an issue in 3.6 and 4.0. |
| Comments |
| Comment by Arun Banala [ 17/Jun/20 ] |
|
Closing this a duplicate. |
| Comment by Louis Williams [ 17/Jun/20 ] |
|
I think we should. It seems like it solved the same problem in 4.2. Backporting would avoid implementing a new bug fix on older, more stable branches. |
| Comment by Arun Banala [ 17/Jun/20 ] |
|
louis.williams Yes, Are there any objections to backporting |
| Comment by Louis Williams [ 17/Jun/20 ] |
|
Would backporting |