[SERVER-49695] Clarify and correct synchronization of isOplogTruncateAfterPointBeingUsedForPrimary Created: 17/Jul/20  Updated: 29/Oct/23  Resolved: 29/Aug/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.7.0, 4.4.5

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-47898 Advancing lastDurable irrespective of... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4
Sprint: Execution Team 2020-08-24, Execution Team 2020-09-07
Participants:
Linked BF Score: 8

 Description   

The variable _isPrimary in replication_consistency_markers_impl.cpp is used to signal whether or not to write out the oplog truncation point during journal flushing. However, it is not synchronized with the actual write to the truncation point. The code which clears it attempts to work around this by interrupting and waiting for the journal flusher, but the journal flusher is not safely interruptible at this point.



 Comments   
Comment by Githook User [ 23/Feb/21 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-49695 The waitUntilDurable() codepath should not fassert success of oplogTruncateAfterPoint update

(cherry picked from commit 57ed7ccb3ea367c8f59eeb6cb9160421c56372ac)
Branch: v4.4
https://github.com/mongodb/mongo/commit/4477891e30a89af42bbb277de4aa9592e57fd25e

Comment by Githook User [ 29/Aug/20 ]

Author:

{'name': 'Dianna Hohensee', 'email': 'dianna.hohensee@mongodb.com', 'username': 'DiannaHohensee'}

Message: SERVER-49695 The waitUntilDurable() codepath should not fassert success of oplogTruncateAfterPoint update
Branch: master
https://github.com/mongodb/mongo/commit/57ed7ccb3ea367c8f59eeb6cb9160421c56372ac

Comment by Dianna Hohensee (Inactive) [ 27/Aug/20 ]

I think it would be best to make a new ReplicationConsistencyMarkers class private function that calls the ReplicationConsistencyMarkers::setOplogTruncateAfterPoint() logic without the fassert, and modify the existing setOplogTruncateAfterPoint() function to be a wrapper thereof. I believe we only need to worry about ReplicationConsistencyMarkers functions fassert'ing and not any direct external callers of setOplogTruncateAfterPoint().

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