summaryrefslogtreecommitdiff
path: root/src/mongo/db
diff options
context:
space:
mode:
authorLouis Williams <louis.williams@mongodb.com>2019-06-11 13:10:01 -0400
committerLouis Williams <louis.williams@mongodb.com>2019-06-11 13:10:01 -0400
commit01e68d5ac26a64b5b2d3a836428c07e3874488bf (patch)
treeae5151b3dddf6aa927c9a5c18030985ee9e5d149 /src/mongo/db
parentcc24f2022c761b32eecb18f6f5c841c3a43fe7c1 (diff)
downloadmongo-01e68d5ac26a64b5b2d3a836428c07e3874488bf.tar.gz
Revert "SERVER-41361 Do not read at lastApplied while already holding the PBWM lock on secondaries"
This reverts commit b6ad5c431b8a1272617a3eff58872808afa53e31.
Diffstat (limited to 'src/mongo/db')
-rw-r--r--src/mongo/db/db_raii.cpp11
1 files changed, 3 insertions, 8 deletions
diff --git a/src/mongo/db/db_raii.cpp b/src/mongo/db/db_raii.cpp
index 38be0bf62d8..3d111f8a195 100644
--- a/src/mongo/db/db_raii.cpp
+++ b/src/mongo/db/db_raii.cpp
@@ -179,7 +179,7 @@ AutoGetCollectionForRead::AutoGetCollectionForRead(OperationContext* opCtx,
// waiting for the lastAppliedTimestamp to move forward. Instead we force the reader take
// the PBWM lock and retry.
if (lastAppliedTimestamp) {
- LOG(0) << "tried reading at last-applied time: " << *lastAppliedTimestamp
+ LOG(2) << "Tried reading at last-applied time: " << *lastAppliedTimestamp
<< " on ns: " << nss.ns() << ", but future catalog changes are pending at time "
<< *minSnapshot << ". Trying again without reading at last-applied time.";
// Destructing the block sets _shouldConflictWithSecondaryBatchApplication back to the
@@ -229,13 +229,8 @@ bool AutoGetCollectionForRead::_shouldReadAtLastAppliedTimestamp(
const NamespaceString& nss,
repl::ReadConcernLevel readConcernLevel) const {
- // If we are already holding the PBWM lock, do not read at last-applied. This is because once an
- // operation reads without a timestamp (effectively seeing all writes), it is no longer safe to
- // start reading at a timestamp, as writes or catalog operations may appear to vanish.
- // This may occur when multiple collection locks are held concurrently, which is often the case
- // when DBDirectClient is used.
- if (opCtx->lockState()->isLockHeldForMode(resourceIdParallelBatchWriterMode, MODE_IS)) {
- LOG(1) << "not reading at last-applied because the PBWM lock is held";
+ // If external circumstances prevent us from reading at lastApplied, disallow it.
+ if (!_shouldNotConflictWithSecondaryBatchApplicationBlock) {
return false;
}