[SERVER-33736] Vectored inserts incorrectly timestamp index updates Created: 08/Mar/18  Updated: 29/Oct/23  Resolved: 23/May/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 3.6.0, 3.7.1
Fix Version/s: 4.0.0-rc1, 4.1.1

Type: Bug Priority: Major - P3
Reporter: Daniel Gottlieb (Inactive) Assignee: Eric Milkie
Resolution: Fixed Votes: 0
Labels: PM-834
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Problem/Incident
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0, v3.6
Sprint: Storage NYC 2018-05-21, Storage NYC 2018-06-04
Participants:
Linked BF Score: 0

 Description   

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:

  1. Insert new document into the record store.
  2. For each index, calculate the document's index key and update the index.

A vectored insert instead works as:

  1. Insert document A into the record store.
  2. Insert document B into the record store.
  3. Calculate and update indexes for A.
  4. Calculate and update indexes for B.

Performing the same actions but adding in timestamps:

  1. Set the timestamp to T(A).
  2. Insert document A into the record store (gets T(A)).
  3. Set the timestamp to T(B).
  4. Insert document B into the record store (gets T(B)).
  5. Update indexes for A (gets T(B)).
  6. 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.



 Comments   
Comment by Githook User [ 24/May/18 ]

Author:

{'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}

Message: SERVER-33736 do not run jstest on mobile

(cherry picked from commit 43403ac1eace3d0cd95ecd33cd1eb101b274a34c)
Branch: v4.0
https://github.com/mongodb/mongo/commit/ee4991b1d2dcb9442531dc7ba0ce4b134ba4f25c

Comment by Githook User [ 24/May/18 ]

Author:

{'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}

Message: SERVER-33736 do not run jstest on mobile
Branch: master
https://github.com/mongodb/mongo/commit/43403ac1eace3d0cd95ecd33cd1eb101b274a34c

Comment by Githook User [ 23/May/18 ]

Author:

{'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}

Message: SERVER-33736 timestamp index updates from vector inserts

(cherry picked from commit 2ac08ad44e8218de90228ae948cd3abc6f4d99eb)
Branch: v4.0
https://github.com/mongodb/mongo/commit/6c0d5a86180cee650c3b149009189e623c1af8f1

Comment by Githook User [ 23/May/18 ]

Author:

{'username': 'milkie', 'name': 'Eric Milkie', 'email': 'milkie@10gen.com'}

Message: SERVER-33736 timestamp index updates from vector inserts
Branch: master
https://github.com/mongodb/mongo/commit/2ac08ad44e8218de90228ae948cd3abc6f4d99eb

Comment by Eric Milkie [ 02/Apr/18 ]

This work is only necessary to ensure that atClusterTime works properly. Global Point in Time Reads is the only project that will consume atClusterTime, so this work can be done as part of the completion of GPITR.

Generated at Thu Feb 08 04:34:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.