[SERVER-43656] Return the timestamp of the top of the oplog in the storage integration layer Created: 26/Sep/19  Updated: 29/Oct/23  Resolved: 23/Oct/19

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: 4.3.1

Type: Improvement Priority: Major - P3
Reporter: Judah Schvimer Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-39364 Audit uses of setLastOpToSystemLastOp... Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2019-10-21, Execution Team 2019-11-04
Participants:

 Description   

This is needed to fix a replication bug described in SERVER-39364. Please keep any discussion about whether we should do this approach to that ticket, and any discussion about the implementation of this function to this ticket.



 Comments   
Comment by Githook User [ 23/Oct/19 ]

Author:

{'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb'}

Message: SERVER-43656: Add an optimized method for querying the latest entry in the oplog.
Branch: master
https://github.com/mongodb/mongo/commit/19b9e3fc31506fd6d8e2f629e5d3f3d0dbf80918

Comment by Daniel Gottlieb (Inactive) [ 11/Oct/19 ]

Adding a clarification. The behavior could be satisfied by the caller instead doing a reverse cursor scan on the oplog. However, storage is going to expose a more robust/flexible/efficient solution (at the expense of adding an API method) that avoids parsing BSON and doesn't depend on/muck with the WT_SESSION/TXN state on the caller's recovery unit.

Generated at Thu Feb 08 05:03:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.