-
Type: Improvement
-
Resolution: Incomplete
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Storage
-
Labels:None
-
Execution Team 2020-06-15, Execution Team 2020-07-13
The goal here is to allow for ghost timestamps in spirit, but better control the timestamp used to avoid out-of-order update chains (e.g: 10->20->100->40).
When a ghost timestamp is required instead of looking at the logical clock, attempt to perform:
- Acquire PBWM + RSTL (whichever the right order is)
- If primary, write a no-op oplog entry
- If secondary, ghost timestamp with last-applied
Claims that need to be verified:
- All usages of ghost timestamps are capable of acquiring the PBWM
- last-applied is sufficient for avoiding out-of-order update chains
- Choosing an earlier value doesn't persist something that's intended to be rolled back. I heard of that behavior being relied upon a while back, but I'm not too familiar and am unsure if the behavior still exists.