[SERVER-34381] 3.6 Majority read concern can read data mid-rollback Created: 09/Apr/18  Updated: 27/Oct/23  Resolved: 18/Apr/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.6.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Spencer Brody (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

In 3.6, we do not prevent majority reads at a timestamp between the common point and reaching minValid. The data is inconsistent during this period of time, so we should not service reads that use timestamps during this period. This is only a problem for rollback via refetch.



 Comments   
Comment by Spencer Brody (Inactive) [ 18/Apr/18 ]

In 3.6 we maintain a list of _stableTimestampCandidates which only get set to optimes that are consistent (i.e. when we're not less than our minvalid).

We then only update our committed snapshot (which is what we use to serve majority reads) to stable timestamp candidates.

So I think we're safe from this.

Comment by Gregory McKeon (Inactive) [ 12/Apr/18 ]

This may be a problem for majority readConcern on the inmemory storage engine in 4.0 as well.

Generated at Thu Feb 08 04:36:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.