[SERVER-48129] Invariant that operations which are holding open an oplog hole cannot block when acquiring locks Created: 12/May/20  Updated: 29/Oct/23  Resolved: 13/Jul/21

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

Type: Improvement Priority: Major - P3
Reporter: James Heppenstall Assignee: Gregory Wlodarek
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-46698 Invariant that operations which are h... Closed
Related
is related to SERVER-58223 Investigate shard_server_op_observer.... Open
is related to SERVER-58243 Investigate transaction_participant.c... Open
is related to SERVER-58222 Investigate op_observer_sharding_impl... Backlog
is related to SERVER-58219 Investigate ViewCatalog::reload() loc... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2021-06-28, Execution Team 2021-07-12, Execution Team 2021-07-26
Participants:

 Description   

SERVER-46698 invariants that operations which are holding open an oplog hole cannot acquire a storage engine ticket or flow control ticket.

We also attempted to invariant when acquiring a lock, namely in LockerImpl::_lockBegin and LockerImpl::_lockComplete, but discovered that a MODE_IX lock on the session transactions table is acquired while holding open an oplog hole in at least two different code paths.

  1. In logApplyOpsForTransaction, an oplog hole is opened (via RecoveryUnit::setTimestamp) by logOperation. A MODE_IX lock on the session transactions table is then acquired here by onWriteOpCompleted (via updateSessionEntry in onWriteOpCompletedOnPrimary).
  2. In OpObserverImpl::onInserts, an oplog hole is opened by repl::logInsertOps. A MODE_IX lock on the session transactions table is then acquired here by onWriteOpCompleted (via updateSessionEntry in onWriteOpCompletedOnPrimary).

The goal of this ticket should be to (a) determine whether acquiring the MODE_IX lock on the session transactions table can actually block in practice (perhaps another thread acquires a MODE_X or MODE_S lock on the session transactions table) and to (b) invariant that operations which are holding open an oplog hole cannot block when acquiring locks.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 13/Jul/21 ]

Author:

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

Message: SERVER-48129 Invariant that operations which are holding open an oplog hole cannot block when acquiring locks
Branch: master
https://github.com/mongodb/mongo/commit/5a2e80c11092052b88ddaffe002ca32438b1fe5a

Comment by Githook User [ 13/Jul/21 ]

Author:

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

Message: SERVER-48129 Add new AllowLockAcquisitionOnTimestampedUnitOfWork RAII type
Branch: master
https://github.com/mongodb/mongo/commit/4647a428aa53b84dc2b619e87875eff6653d7b08

Comment by Githook User [ 13/Jul/21 ]

Author:

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

Message: SERVER-48129 Remove unused variables in AutoGetOplog
Branch: master
https://github.com/mongodb/mongo/commit/024707a98614c24d10e8ab0c61c27642672a182a

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