[SERVER-30963] oplog_test should protect access to logOp() with a mutex when using the ephemeralForTest storage engine Created: 06/Sep/17  Updated: 30/Oct/23  Resolved: 19/Sep/17

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.6.0-rc0

Type: Bug Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-30212 Use two phase drop for renameCollecti... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2017-09-11, Repl 2017-10-02
Participants:
Linked BF Score: 0

 Description   

The intent of the test, introduced in SERVER-30212, is to verify multiple uncommitted WriteUnitOfWork that have oplog optimes assigned by repl::logOp() and not to stress the ephemeralForTest storage engine's support for concurrent document insert operations on the oplog collection. By synchronizing access to repl::logOp() with the mutex that's already present in the tests, we can still preserve the existing test cases in oplog_test.cpp which illustrate how logOp() works with storage engines that support document level concurrency.



 Comments   
Comment by Githook User [ 19/Sep/17 ]

Author:

{'username': 'benety', 'name': 'Benety Goh', 'email': 'benety@mongodb.com'}

Message: SERVER-30963 synchronize access to logOp() in oplog_test
Branch: master
https://github.com/mongodb/mongo/commit/ec46024f5b5dbc8be4b71c014a45ba97c3c38f06

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