SERVER-39356 Refactor speculative majority read data structures and methods to use timestamps instead of optimes

This patch refactors the SpeculativeMajorityReadInfo class and the awaitOpTimeCommitted method to accept timestamps as input instead of optimes. When waiting for an operation to majority commit, term information, which is included in optimes, isn't necessary, since timestamps are totally ordered within a local oplog, and so are safely comparable. It is, for example, safe to determine if a local oplog entry is majority committed by checking if its timestamp is less than that node's local view of the majority commit point. This patch should not introduce any observable functional changes.

1 files changed, 10 insertions, 6 deletions

diff --git a/src/mongo/db/repl/replication_coordinator.h b/src/mongo/db/repl/replication_coordinator.h
index b61b2e71495..684f0377e7a 100644
--- a/src/mongo/db/repl/replication_coordinator.h
+++ b/src/mongo/db/repl/replication_coordinator.h
@@ -389,17 +389,21 @@ public:
                                                boost::optional<Date_t> deadline) = 0;
 
     /**
-     * Wait until the given optime is known to be majority committed.
+     * Waits until the timestamp of this node's lastCommittedOpTime is >= the given timestamp.
      *
-     * The given optime is expected to be an optime in this node's local oplog. This method cannot
-     * determine correctly whether an arbitrary optime is majority committed within a replica set.
-     * It is expected that the execution of this method is contained within the span of one user
-     * operation, and thus, should not span rollbacks.
+     * Note that it is not meaningful to ask, globally, whether a particular timestamp is majority
+     * committed within a replica set, since timestamps do not uniquely identify log entries. Upon
+     * returning successfully, this method only provides the guarantee that the given timestamp is
+     * now less than or equal to the timestamp of the majority commit point as known by this node.
+     * If the given timestamp is associated with an operation in the local oplog, then it is safe to
+     * conclude that that operation is majority committed, assuming no rollbacks occurred. It is
+     * always safe to compare commit point timestamps to timestamps in a node's local oplog, since
+     * they must be on the same branch of oplog history.
      *
      * Returns whether the wait was successful. Will respect the deadline on the given
      * OperationContext, if one has been set.
      */
-    virtual Status awaitOpTimeCommitted(OperationContext* opCtx, OpTime opTime) = 0;
+    virtual Status awaitTimestampCommitted(OperationContext* opCtx, Timestamp ts) = 0;
 
     /**
      * Retrieves and returns the current election id, which is a unique id that is local to