Details
-
Task
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
-
Fully Compatible
-
Repl 2018-01-15, Repl 2018-01-29, Repl 2018-02-12
Description
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.
Attachments
Issue Links
- 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
-