[SERVER-62510] ephemeralForTest oplog visibility bug Created: 11/Jan/22  Updated: 27/Oct/23  Resolved: 27/Apr/22

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

Type: Bug Priority: Major - P3
Reporter: Louis Williams Assignee: Backlog - Storage Execution Team
Resolution: Gone away Votes: 0
Labels: EFT
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Linked BF Score: 15

 Description   

EFT does not correctly implement oplog visibility. It checks the "all committed" value after forking and obtaining a snapshot. This means that the highest-visible point in the oplog can actually reflect uncommmited operations in the oplog cursor's snapshot.

For example. Say operations with timestamps T1 and T3 are committed, but T2 is not. The "all committed" (aka "highest visible") operation should be T1.

Consider the sequence:

  • An oplog reader obtains a snapshot. T1 and T3 are visible, T2 is not.
  • T2 commits in parallel
  • The oplog reader opens a cursor sees the highest visible record as T3. The operation returns T1 and T3, but skips T2.

See SERVER-38499 for details on how this was implemented in MongoDB.



 Comments   
Comment by Louis Williams [ 11/Jan/22 ]

We should probably just disable this test on EFT

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