A vectored insert is when one WriteUnitOfWork (transaction) performs multiple document inserts before committing. This mechanism is used on primaries for bulk writes and secondaries during oplog application.
A typical insert executes in the order of:
- Insert new document into the record store.
- For each index, calculate the document's index key and update the index.
A vectored insert instead works as:
- Insert document A into the record store.
- Insert document B into the record store.
- Calculate and update indexes for A.
- Calculate and update indexes for B.
Performing the same actions but adding in timestamps:
- Set the timestamp to T(A).
- Insert document A into the record store (gets T(A)).
- Set the timestamp to T(B).
- Insert document B into the record store (gets T(B)).
- Update indexes for A (gets T(B)).
- Update indexes for B (gets T(B)).
Scanning the collection at T(A) will show document A, but searching for A via an index will not succeed.
Secondaries are currently immune to observing this anomaly; read timestamps on a secondary (e.g: majority reads) must take place on a batch boundary. This was intended to ensure that unique indexes could not be observed in a temporarily inconsistent state.