SERVER-47582 clearing the oplogTruncateAfterPoint during stepdown must not take the PBWM

(cherry picked from commit da4a8e0e85627d6febd8bce3fd87f221e0ff97c6)

1 files changed, 4 insertions, 0 deletions

diff --git a/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp b/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
index d49f19f7c99..422d8f6d02d 100644
--- a/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
+++ b/src/mongo/db/repl/replication_coordinator_external_state_impl.cpp
@@ -803,6 +803,10 @@ void ReplicationCoordinatorExternalStateImpl::stopAsyncUpdatesOfAndClearOplogTru
     // above, if writing is imminent, so we must make sure that the code completes fully.
     _service->getStorageEngine()->waitForJournalFlush(opCtx);
 
+    // Writes to non-replicated collections do not need concurrency control with the OplogApplier
+    // that never accesses them. Skip taking the PBWM.
+    ShouldNotConflictWithSecondaryBatchApplicationBlock shouldNotConflictBlock(opCtx->lockState());
+
     // We can clear the oplogTruncateAfterPoint because we know there are no user writes during
     // stepdown and therefore presently no oplog holes.
     _replicationProcess->getConsistencyMarkers()->setOplogTruncateAfterPoint(opCtx, Timestamp());