Skip to content
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

(release/v1.6) levels: Compaction incorrectly drops some delete markers (#1422) #1507

Merged
merged 3 commits into from
Sep 9, 2020

Conversation

NamanJain8
Copy link
Contributor

@NamanJain8 NamanJain8 commented Sep 8, 2020

fd89894 ("Compaction: Expired keys and delete markers are never
purged") revealed a bug in the compaction logic that leads to delete
markers being incorrectly dropped during compaction.

During compaction, *levelsController.compactBuildTables decides to
drop a delete key if there is no overlap with levels lower than the
bottom layer of the compaction definition.

It does that by checking only the top table, thinking that proving
that the top table doesn't overlap is sufficient to prove that
the bottom table doesn't. Unfortunately, this is not the case.
Not in general, and even less in the case of DropPrefix() where
we run a same-level compaction and top is empty.

The faulty condition was introduced way back when in e597fb7
("Discard key versions during compaction").

(cherry picked from commit 5b90893)


This change is Reviewable

fd89894 ("Compaction: Expired keys and delete markers are never
purged") revealed a bug in the compaction logic that leads to delete
markers being incorrectly dropped during compaction.

During compaction, `*levelsController.compactBuildTables` decides to
drop a delete key if there is no overlap with levels lower than the
bottom layer of the compaction definition.

It does that by checking only the `top` table, thinking that proving
that the `top` table doesn't overlap is sufficient to prove that
the `bottom` table doesn't. Unfortunately, this is not the case.
Not in general, and even less in the case of `DropPrefix()` where
we run a same-level compaction and `top` is empty.

The faulty condition was introduced way back when in e597fb7
("Discard key versions during compaction").

(cherry picked from commit 5b90893)
@NamanJain8 NamanJain8 requested a review from a team September 8, 2020 08:46
@NamanJain8 NamanJain8 changed the title levels: Compaction incorrectly drops some delete markers (#1422) (release/v1.6) levels: Compaction incorrectly drops some delete markers (#1422) Sep 8, 2020
Copy link
Contributor

@jarifibrahim jarifibrahim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewable status: 0 of 2 files reviewed, all discussions resolved (waiting on @ashish-goswami, @jarifibrahim, and @manishrjain)

Copy link
Contributor

@jarifibrahim jarifibrahim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 2 files reviewed, all discussions resolved (waiting on @ashish-goswami and @manishrjain)

@NamanJain8 NamanJain8 merged commit d583154 into release/v1.6 Sep 9, 2020
@NamanJain8 NamanJain8 deleted the naman/cp-11 branch September 9, 2020 14:39
mYmNeo pushed a commit to mYmNeo/badger that referenced this pull request Jan 16, 2023
…c#1422) (hypermodeinc#1507)

fd89894 ("Compaction: Expired keys and delete markers are never
purged") revealed a bug in the compaction logic that leads to delete
markers being incorrectly dropped during compaction.

During compaction, `*levelsController.compactBuildTables` decides to
drop a delete key if there is no overlap with levels lower than the
bottom layer of the compaction definition.

It does that by checking only the `top` table, thinking that proving
that the `top` table doesn't overlap is sufficient to prove that
the `bottom` table doesn't. Unfortunately, this is not the case.
Not in general, and even less in the case of `DropPrefix()` where
we run a same-level compaction and `top` is empty.

The faulty condition was introduced way back when in e597fb7
("Discard key versions during compaction").

(cherry picked from commit 5b90893)

Co-authored-by: Damien Tournoud <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants