-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
storage,kv: fixes for enabling separated intents
The main part of this PR is a reworking of the bounds behavior of intentInterleavingIter and a clarification of that behavior in engine.go. The existing behavior was subtly broken in two ways: - iteration up from local keys without an upper bound or an upper bound that was a global key could cause the iterator to enter an error state when it found a separated intent without the corresponding provisional value. Similarly, the behavior when iterating backwards from global keys without a lower bound, or a lower bound that was a local key would encounter an error. There are additional tests that exercise this (the earlier tests did not construct an engine with both local and global keys and therefore missed this problem). - even if we could fix the inconsistency from the previous bullet, there is a semantic concern that a caller that sets a global upper bound (local lower bound) and seeks to a local key (global key) and then iterates forward (backward) is expecting this iteration to seamlessly go from local (global) to global (local) keys, which is not something we can do with intentInterleavingIter since it would require it to transparently jump over the intermediate lock table. I didn't expect there were callers trying to do this, but there are: we have multiple places that have both local and global spans, and create an iterator with an upperbound that is the end of the highest global span and then SeekGE to the start of the smallest local span. They are not actually trying to go from local to global without an intermediate seek, but it is impossible to know their intention from the iterator interface. Such behavior is no longer allowed, since intentInterleavingIter is very strict about ensuring that if it is constrained to local (global) keys, all seek and SetUpperBound calls are using the same kind of key. Without such strictness we are at risk of introducing hard-to-find correctness bugs. Additionally, we now place the lock table keys at the end of the local key space, after the local store keys. This is convenient for cleanly separating the two parts of the key space that a caller iterates over using an MVCCIterator (even though local store keys don't have versions). intentInterleavingIter is simpler with the above fixes: - The compex upper-bound behavior for prefix iteration is ripped out. It was never needed since pebble.Iterator is very strict about not exposing keys that don't match the prefix. - The constraint on whether the iterator is over local or global keys or unconstrained (only for prefix iteration because of the previous bullet), is computed at iterator construction time. The callers mentioned above are now fixed. They now create new iterators for each span, or lazily create a new one if the existing iterator was constrained differently. Creating a new iterator is usually cheap because of iterator reuse. One exception is that pebbleSnapshot does not reuse iterators -- I tried to add reuse there but I can't add it directly to pebbleSnapshot itself since callers may be expecting to the use the same snapshot in multiple goroutines. And wrapping pebbleSnapshot for iterator reuse in a single goroutine is complicated because the snapshot may have been wrapped in other Reader implementations. I suspect the iterator construction is not going to performance critical for these snapshot use cases, but could use a more informed opinion. Related to the above, SetUpperBound is now deprecated for MVCCIterator and EngineIterator. Informs #41720 Release note: None
- Loading branch information
1 parent
995d716
commit 83fbe72
Showing
36 changed files
with
1,243 additions
and
333 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.