-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Storage
-
Fully Compatible
-
Repl 2018-01-15, Repl 2018-01-29, Repl 2018-02-12
There are two cases to resolve. The first is easier. The second is a little trickier:
When a document is inserted/updated into a collection that can require multiple entries in an index (e.g: the value of an indexed field is an array), the index's "multikey" field must be set to true.
This update is currently done as a side-transaction to avoid write conflicts. Being a side-transaction throws away the ability to inherit a timestamp from the insert/update request.
Proposed solutions can be classified as:
- Remove the side transaction. Solutions here have varying degrees of effort to still allow for serialization of updates to the document to prevent a worst case scenario where progress slows down (stops?)
- Assign a timestamp to the write that is at least as early as any updates that are part of the request requiring this update.
- A bit more clever, introduce an error case when inserts require the multikey field to be changed to true. Top-level handlers should translate this error to setting multikey to true (in a "before?-transaction") followed by performing the insert. An explicit timestamp would still need to be chosen, but there might be less plumbing required to make the timestamp and transaction meet.
- causes
-
SERVER-33106 Triggering an exception in BtreeKeyGeneratorV1::getKeysImpl() prevents an index from ever becoming multikey
- Closed
- is depended on by
-
SERVER-32284 awaitReplication can hang when the optime to wait for does not match the minSnapshot.
- Closed
-
SERVER-30809 Investigating remaining writes to the [KV]Catalog that must be timestamped.
- Closed
- is related to
-
SERVER-29213 Have KVWiredTigerEngine implement StorageEngine::recoverToStableTimestamp
- Closed
- related to
-
SERVER-33675 move multi key tracking from multiSyncApply to multiSyncApply_noAbort
- Closed