When a storage transaction to update an index to multikey is aborted, it is possible for the in-memory state of an index to appear as multikey but the durable state to remain as non-multikey.
In this scenario, the IndexCatalogEntryImpl (erroneous in-memory state) may contain path-level information which lead to this optimization being erroneously applied to subsequent multikey writes and leaving the index as non-multikey in the catalog.
- is related to
-
SERVER-41766 Secondary may encounter prepare conflict when applying write that sets the multikey flag
- Closed
-
SERVER-43757 background validate must skip indexes whose persisted and in-memory idents do not match
- Closed
-
SERVER-47694 fix multikey. again
- Closed
-
SERVER-47812 Secondaries persist wildcard multikeypaths out of order
- Closed
-
SERVER-56002 listIndexes can read partial state from renameCollection
- Closed
-
SERVER-56023 listCollections can return empty metadata for a collection which has been concurrently dropped
- Closed
-
SERVER-57127 Refactor multikey and other state out of IndexCatalogEntry
- Closed
-
SERVER-53675 Allow validate to fix up multikey metadata
- Closed
- related to
-
SERVER-56882 unable to complete full validation on collection after failed hashed index insert
- Closed
-
SERVER-57775 collection metadata for multikey not removed after WriteConflictException from durable catalog update
- Closed
-
SERVER-92433 Multikey indexes can be mistakenly treated as non-multikey indexes
- Closed
-
SERVER-57178 add regression test for multikey compound index
- Closed
-
SERVER-57268 add multikey query to validate_multikey_restart.js
- Closed