summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMoustafa Maher Khalil <m.maher@mongodb.com>2022-01-11 21:49:55 +0000
committerEvergreen Agent <no-reply@evergreen.mongodb.com>2022-02-19 01:28:18 +0000
commit45d84929f04b99b882195c3b6c0333c91438e108 (patch)
tree432ddfb42a40d0f11b13efe7f6c5b64123f525e4
parent78858e1cb9b2c69cbd3c122e4ff7fee2246bd3ab (diff)
downloadmongo-45d84929f04b99b882195c3b6c0333c91438e108.tar.gz
SERVER-62379 Fix deadlock between ReplicationCoordinator and BackgroundSync on stepUp
-rw-r--r--src/mongo/db/repl/bgsync.cpp6
1 files changed, 5 insertions, 1 deletions
diff --git a/src/mongo/db/repl/bgsync.cpp b/src/mongo/db/repl/bgsync.cpp
index 0cd8e9afd4e..425f0df28cd 100644
--- a/src/mongo/db/repl/bgsync.cpp
+++ b/src/mongo/db/repl/bgsync.cpp
@@ -482,6 +482,10 @@ void BackgroundSync::_produce() {
{
auto opCtx = cc().makeOperationContext();
+ // Calling getMyLastAppliedOpTime has to be outside bgsync mutex, to preserve proper lock
+ // ordering because it acquires replication coordinator's mutex .
+ auto lastAppliedOpTime = _replCoord->getMyLastAppliedOpTime();
+
// Check if the producer has been stopped so that we can prevent setting the applied point
// after step up has already cleared it. We need to acquire the collection lock before the
// mutex to preserve proper lock ordering.
@@ -499,7 +503,7 @@ void BackgroundSync::_produce() {
// TODO SERVER-53642: With Lock Free Reads we may have readers on lastAppliedOpTime so
// we cannot use this timestamp in a write.
_replicationProcess->getConsistencyMarkers()->setAppliedThrough(
- opCtx.get(), _replCoord->getMyLastAppliedOpTime(), false);
+ opCtx.get(), lastAppliedOpTime, false);
}
}