[SERVER-27099] Consider removing comparison operators from OpTime class Created: 17/Nov/16 Updated: 19/Apr/17 Resolved: 19/Apr/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Sprint: | Repl 2017-03-27, Repl 2017-04-17, Repl 2017-05-08 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Comparing OpTimes from different terms is fundamentally problematic as they could be from different branches of history. Every time we compare two optimes without checking that they come from the same term is suspicious. We at least need to audit all places where do do optime comparisons, and we should consider removing the optime comparison operators entirely so all places that compare optimes must think about term differences explicitly. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 19/Apr/17 ] |
|
We definitely need to be careful whenever we're comparing optimes, but I don't think this is the way to enforce that. |
| Comment by Spencer Brody (Inactive) [ 18/Nov/16 ] |
|
They do, and we compare the term before the timestamp, the problem is that you can't actually assume that optimes from different terms have a happens-before relationship as they may come from different branches of history (one of which will later roll back). This is how you get the issues like |
| Comment by Andy Schwerin [ 18/Nov/16 ] |
|
Shouldn't optime objects just contain the term? |