[SERVER-37342] Do not store the RecordId in the KeyString for unique indexes in BiggieSE Created: 27/Sep/18  Updated: 29/Oct/23  Resolved: 03/Nov/18

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.1.5

Type: Bug Priority: Major - P3
Reporter: Gregory Wlodarek Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Storage NYC 2018-10-08, Storage NYC 2018-10-22, Storage NYC 2018-11-05
Participants:

 Description   

Storing the RecordId in the KeyString on unique indexes causes our namespaces to become corrupted on highly parallel workloads such as the jstest/core/bench_test3.js.

The area of concern is when the collection is initially empty and two different threads attempt to insert the same document with the same value on a unique index. Since each thread is working in its own snapshot, it will not see the insert made by the other thread and if we use the RecordId in the KeyString, then upon merging, we will not have a conflict since both of the documents would have differing RecordIds. So for unique indexes, we shouldn't store the RecordId in the KeyString but in the value pointed to with the KeyString.



 Comments   
Comment by Githook User [ 03/Nov/18 ]

Author:

{'name': 'Gregory Wlodarek', 'email': 'gregory.wlodarek@mongodb.com', 'username': 'GWlodarek'}

Message: SERVER-37342 Do not store the RecordId in the KeyString for unique indexes in BiggieSE
Branch: master
https://github.com/mongodb/mongo/commit/bb8a75e904bb2accb192772126bc319cd16646a4

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