[SERVER-18346] Investigate interaction of CollectionInfoCache::addedIndex()/droppedIndex() and IndexCatalogEntry DEV consistency checks Created: 06/May/15 Updated: 06/Dec/22 Resolved: 22/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Currently IndexCatalogEntry dasserts that the in-memory cache matches the storage-engine view of the catalog. Among other things this means that CIC::reset() needs to be very careful about what methods it calls on the ICE since CIC::reset() is called during rollback where it is illegal to query the storage engine. |
| Comments |
| Comment by Eric Milkie [ 22/May/18 ] |
|
The code has been changed since this ticket was filed, and the ICE no longer makes the checks described in the ticket. |
| Comment by J Rassi [ 14/Apr/16 ] |
|
CollectionInfoCache::addedIndex() and CollectionInfoCache::droppedIndex() indeed replace CollectionInfoCache::reset(), but the same issue still applies to them. |
| Comment by Kyle Suarez [ 14/Apr/16 ] |
|
Note that as of |