[SERVER-17887] Overflow generated OpTimes from i field into t field Created: 03/Apr/15  Updated: 31/Mar/17  Resolved: 27/Mar/17

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

Type: Improvement Priority: Major - P3
Reporter: Eric Milkie Assignee: William Schultz (Inactive)
Resolution: Duplicate Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Duplicate
duplicates SERVER-28352 Fix ticks increment in LogicalCLock::... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.4, v3.2
Sprint: Repl 2017-02-13, Repl 2017-03-06, Repl 2017-03-27, Repl 2017-04-17
Participants:

 Description   

Currently, if the i field of the global OpTime on a server increments past signed int max, we abort the process:

     if (val.getInc() & 0x80000000) {
            mongo::warning() << "clock skew detected  prev: " << val.getSecs()
                             << " now: " << (unsigned) time(0) << std::endl;
            return true;
        }

Instead, we could handle this by incrementing the "secs" field by one and resetting the "inc" field back to 1. (The code resets the inc field back to 1 instead of 0 in the normal case, for some reason.)



 Comments   
Comment by William Schultz (Inactive) [ 27/Mar/17 ]

Addressed by SERVER-28352.

Comment by William Schultz (Inactive) [ 20/Mar/17 ]

As part of the work on the causal consistency project (PM-221), global_timestamp.cpp has been replaced by logical_clock.cpp, and the issue referenced in this ticket is now addressed by SERVER-28352.

We should still decide if we also want to address this issue on an older branch for sake of backport to 3.4/3.2, since I am assuming that the logical clock work will not be backported.

Comment by Spencer Brody (Inactive) [ 07/Dec/16 ]

As part of this we must make sure this fassert in global_timestamp.cpp isn't a problem if the global timestamp overflows the counter in a single second.

Comment by Eric Milkie [ 21/Apr/16 ]

Change of plans. Work on SERVER-18557 will be delayed so the overflow work is still desirable in the near term.

Comment by Eric Milkie [ 20/Apr/16 ]

Instead, we will do SERVER-18557

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