-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
8
While working on WT-6453, I noticed this potential problem. As far as I know, we've never seen this actually happen either in standalone WiredTiger testing or in MongoDB.
Here, we populate the transaction's pinned_id with the oldest running transaction at the time of beginning a cursor operation. This stops us from moving the oldest_id forward past this point. This is the primary mechanism that stops other threads from considering our updates obsolete and freeing them from underneath us. A globally visible update can't come after we've begun reading the chain because if it came after we started, then by definition it can't be globally visible.
Our use of id=0 in history store tombstones breaks this assumption that new things won't somehow "become" globally visible after the fact. Consider this example:
oldest_ts=6, oldest_id=150 U3@t0,id=0 -> U2@t5,id=100 (reader here) -> U1@t4,id=50
The oldest_id will normally stop subsequent updates from being considered globally visible leading to obsoletion. This is because if we open new transactions, their ids will be greater than the one we've pinned. The use of (t0,id=0) sidesteps this assumption and the update chain can be considered obsolete despite readers looking at these updates.