As mentioned in WT-5869, if we don't insert the out of order timestamp updates to the history store, we may run into visibility problems if we read without timestamp and the ignored update is the first update visible to the reader. We have decided to pin the out of order timestamp in the cache until everything becomes obsolete to solve this. Pay attention to the fallout of this change. It may cause issue to test/format and impact the performance.

Also should we differentiate the cases that update is out of timestamp order and updates without timestamp? Currently we remove all the content of the key from the history store if we see an update without timestamp is inserted into the history store. In this case, the update older than the update without timestamp is an out of order timestamp update. If we pin that update in cache, there is no need to actively removing updates from the history store any more. alex.cameron I think we shouldn't differentiate them because the visibility problem is also valid in this case.

Another concern is that we may not be able to close a tree if we don't update the oldest timestamp because we can't evict the pages that have out of order timestamp updates.