[SERVER-48954] Make replication_recovery_test handle doc-level locking storage engine Created: 18/Jun/20  Updated: 29/Oct/23  Resolved: 23/Jun/20

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

Type: Task Priority: Major - P3
Reporter: Henrik Edin Assignee: Henrik Edin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2020-06-29
Participants:

 Description   

Multiple tests in replication_recovery_test.cpp check for which order the oplog applier applies them. When using a storage engine that does not support document-level locking the ordering is guaranteed because all jobs get scheduled on the same replication writer thread because the '_id' field is not used when dispatching the jobs. See this code:

https://github.com/mongodb/mongo/blob/a8af69397f70903f07b3433c03bfc8b1ab92399f/src/mongo/db/repl/oplog_applier_impl.cpp#L190-L201

We should fix these tests so they don't assume this order.



 Comments   
Comment by Githook User [ 22/Jun/20 ]

Author:

{'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}

Message: SERVER-48954 Don't assume oplog apply order in replication_recovery_tests and oplog_applier_impl_test so document-level locking storage engines can be supported
Branch: master
https://github.com/mongodb/mongo/commit/a88e793e77d95170f0a3d2e3f7d59032ef8d6a54

Generated at Thu Feb 08 05:18:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.