BugZero found this defect 116 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
3/14/2024
MongoDB Server
No affected releases provided.
8.0.0-rc0
This came out of an investigation during SERVER-84706. Today, startup recovery for restore first sets the initial data timestamp to the sentinel so that we take unstable checkpoints. We also attempts to set the stable timestamp to Timestamp::min(). However, this is essentially a no-op, as we do not allow trying to reset the stable timestamp if it is null. In addition, it is not safe to set the stable timestamp backwards. After discussion within RSS, we determined that it should be equally performant and safe to set the stable timestamp during startup recovery for restore and take stable checkpoints. This would allow us to advance the stable timestamp alongside the oldest timestamp, preventing any future occurrences of SERVER-84706. We should do this to resolve this bug.
xgen-internal-githook commented on Thu, 14 Mar 2024 03:14:42 +0000: Author: {'name': 'Samy Lanka', 'email': 'samy.lanka@mongodb.com', 'username': 'lankas'} Message: SERVER-85688 Set stable timestamp to end of each oplog batch during startup recover for restore (#19838) GitOrigin-RevId: c64caad420be8ca7084ad4025fac64318ef291d0 Branch: master https://github.com/mongodb/mongo/commit/a56250c06b3a18e75f70e5d77f1904395d1e06ed