-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(compaction): Don't drop data when split overlaps with top tables #1587
Conversation
There was a race condition in the subcompaction code which was caused because we were doing builder.Close after doing throttle.Done in subcomapction. This PR fixes that race condition by calling builder.Done before calling throttle.Done .
… tables" This reverts commit 8957ad4.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
// This will generate splits like [A1 ... C2] . Notice that we | ||
// dropped the C3 which is the last key of the top table. | ||
// See TestCompaction/with_split test. | ||
right := y.KeyWithTs(y.ParseKey(t.Biggest()), math.MaxUint64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getKeyRange takes care of these things. I thought I was using it -- that's the reason for the bug.
In fact, don't we want to consider the right most key? In that case, the right should be using 0 as the version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're generating key ranges using the bot
tables so they don't have the correct key version.
In fact, don't we want to consider the right most key? In that case, the right should be using 0 as the version.
No. We skip the right keys of the key range.
https://github.com/dgraph-io/badger/blob/6c074551f8f5a5b470357236cd90e860d0deb517/levels.go#L666-L668
Badger compactions are split into sub compactions if there are more than 3 tables
bottom tables are involved. The current implementation would drop keys if the top
table would overlap with a bottom table. Consider the following scenario
When this range is compacted, the result was
[ A B C(valid) D ]
(only
C(deleted)
was dropped). The expected result was[A B D]
.This PR fixes the above-mentioned issue. The test in this PR fails on master
but works with this change.
This change is