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-01-11 22:16:45 +0000
commit45188cb0dbf11e9559af07a910bedb8786372bc3 (patch)
tree3d9b92b315ac458470b2b3edcad4235380628f39
parent303071db10ec4e49c4fd7617d9f59828c47ee06e (diff)
downloadmongo-45188cb0dbf11e9559af07a910bedb8786372bc3.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);
}
}