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

Backport facebook/rocksdb#4432 #17

Merged
merged 10 commits into from
Oct 17, 2018
Merged

Backport facebook/rocksdb#4432 #17

merged 10 commits into from
Oct 17, 2018

Conversation

benesch
Copy link

@benesch benesch commented Oct 10, 2018

This backports facebook#4432. The first eight commits are small changes that make the backport apply more cleanly.

@petermattis unfortunately CollapsedRangeDelMap::{ShouldDeleteRange,GetTombstone} fail to compile because they expect user keys but the collapsed range del map now operates on internal keys. As discussed hoping you can take it from here.


This change is Reviewable

benesch and others added 9 commits October 10, 2018 13:07
This makes future backports apply cleanly.
This makes future backports apply cleanly.
Summary:
`CollapsedRangeDelMap` internally uses seqno zero as a sentinel value to
denote a gap between range tombstones or the end of range tombstones. It
therefore expects to never have consecutive sentinel tombstones.

However, since `DeleteRange` is now supported in `SstFileWriter`, an
ingested file may contain range tombstones, and that ingested file may
be assigned global seqno zero. When such tombstones are added to the
collapsed map, they resemble sentinel tombstones due to having seqno
zero. Then, the invariant mentioned above about never having consecutive
sentinel tombstones can be violated.

The symptom of this violation was dereferencing the `end()` iterator
(facebook#4204). The fix in this PR is to not add range tombstones with seqno
zero to the collapsed map. They're not needed anyways since they can't
possibly cover anything (in case of a key and a range tombstone with the
same seqno, the key is visible).
Pull Request resolved: facebook#4216

Differential Revision: D9121716

Pulled By: ajkr

fbshipit-source-id: f5b78a70bea9527354603ea7ac8542a7e2b6a210
Summary:
Add a unit test for range collapsing when non-default comparator is used. This exposes the bug fixed in facebook#4386.
Pull Request resolved: facebook#4388

Differential Revision: D9918252

Pulled By: ajkr

fbshipit-source-id: 99501b96b251eab41791a7e33b27055ee36c5c39
Summary:
We add two subcommands `write_extern_sst` and `ingest_extern_sst` to ldb. This PR avoids changing existing code because we hope to cherry-pick to earlier releases to support compatibility check for external SST file ingestion.
Pull Request resolved: facebook#4205

Differential Revision: D9112711

Pulled By: riversand963

fbshipit-source-id: 7cae88380d4de86da8440230e87eca66755648e4
Add some missing override keywords to make backporting easier. Adapts
upstream commit 33ad906.
This is a partial backport of upstream commit ef7815b ("Support range
deletion tombstones in IngestExternalFile SSTs") to make future
backports cleaner.
)

Summary:
In C++ 11, the order of argument and move evaluation in a statement such
as below is unspecified -
  foo(a.b).bar(std::move(a))
The compiler is free to evaluate std::move(a) first, and then a.b is unspecified.

In C++ 17, this will be safe if a draft proposal around function
chaining rules is accepted.
Pull Request resolved: facebook#4348

Differential Revision: D9688810

Pulled By: anand1976

fbshipit-source-id: e4651d0ca03dcf007e50371a0fc72c0d1e710fb4
Summary:
To more accurately truncate range tombstones at SST boundaries,
we now represent them in RangeDelAggregator using InternalKeys, which
are end-key-exclusive as they were before this change.

During compaction, "atomic compaction unit boundaries" (the range of
keys contained in neighbouring and overlaping SSTs) are propagated down
to RangeDelAggregator to truncate range tombstones at those boundariies
instead. See facebook#4432 (comment) and facebook#4432 (comment)
for motivating examples.
Pull Request resolved: facebook#4432

Differential Revision: D10263952

Pulled By: abhimadan

fbshipit-source-id: 2fe85ff8a02b3a6a2de2edfe708012797a7bd579
@petermattis
Copy link

@benesch Yep, I'll pick this up. Thanks for getting it this far.

@petermattis
Copy link

@benesch I added an additional commit which fixes up the problems with CollapsedRangeDelMap::{ShouldDeleteRange,GetTombstone}. The tests all pass, but I want to give this some more love tomorrow.

Copy link
Author

@benesch benesch left a comment

Choose a reason for hiding this comment

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

Last commit looks pretty good to me, though I haven't reviewed super thoroughly yet.

table/block_based_table_reader.cc Show resolved Hide resolved
AddTombstones(&range_del_agg, {{"a", "d", 20}});
Slice b = "b", c = "c";
ParsedInternalKey b = {"b", kMaxSequenceNumber, kMaxValue};
ParsedInternalKey c {"c", kMaxSequenceNumber, kMaxValue};
VerifyPartialTombstonesEq(PartialRangeTombstone(&b, &c, 10), tombstone);
Copy link
Author

Choose a reason for hiding this comment

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

I think these tests would benefit from cases where a tombstone has been split across multiple files. Perhaps that what you meant by more love.

Choose a reason for hiding this comment

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

Yes, that's exactly what I was referring to. Didn't get around to doing this yet, but it is high on my TODO list.

Choose a reason for hiding this comment

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

I've added a few more test cases that verify behavior in the presence of truncated tombstones. PTAL.

Copy link
Author

Choose a reason for hiding this comment

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

Are you sure you pushed? I'm having trouble finding these new test cases.

Choose a reason for hiding this comment

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

I pushed to the wrong branch. Sorry about that. Take another look.

Copy link
Author

Choose a reason for hiding this comment

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

You're really doubling down on putting these reviews in hard mode, huh?

Change `RangeDelAggregator::GetTombstone,ShouldDeleteRange` to take
internal keys instead of user keys.
range_tombstone_.SetEndKey(nullptr);
if (range_tombstone_.end_key() != nullptr) {
ParsedInternalKey largest;
if (!ParseInternalKey(file_meta_->largest.Encode(), &largest) ||
Copy link
Author

Choose a reason for hiding this comment

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

It is kinda odd that above failing to parse an internal key is an assertion failure and here's it just ignored. But I guess that inconsistency is everywhere in RocksDB, so, ¯_(ツ)_/¯

AddTombstones(&range_del_agg, {{"a", "d", 20}});
Slice b = "b", c = "c";
ParsedInternalKey b = {"b", kMaxSequenceNumber, kMaxValue};
ParsedInternalKey c {"c", kMaxSequenceNumber, kMaxValue};
VerifyPartialTombstonesEq(PartialRangeTombstone(&b, &c, 10), tombstone);
Copy link
Author

Choose a reason for hiding this comment

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

Are you sure you pushed? I'm having trouble finding these new test cases.

Copy link
Author

@benesch benesch left a comment

Choose a reason for hiding this comment

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

LGTM. I can't actually hit the approve button since it's my own PR.

AddTombstones(&range_del_agg, {{"a", "d", 20}});
Slice b = "b", c = "c";
ParsedInternalKey b = {"b", kMaxSequenceNumber, kMaxValue};
ParsedInternalKey c {"c", kMaxSequenceNumber, kMaxValue};
VerifyPartialTombstonesEq(PartialRangeTombstone(&b, &c, 10), tombstone);
Copy link
Author

Choose a reason for hiding this comment

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

You're really doubling down on putting these reviews in hard mode, huh?

@petermattis
Copy link

Not sure what is up with the travis failure. Something timed out ofter 10m. I restarted the job. FYI, I'm also going to backport facebook#4481 and facebook#4476.

@petermattis petermattis merged commit 2d5c6d1 into crl-release-5.13 Oct 17, 2018
@petermattis petermattis deleted the rdfix branch October 17, 2018 13:31
petermattis pushed a commit to benesch/cockroach that referenced this pull request Oct 26, 2018
Picks up cockroachdb/rocksdb#17 and cockroachdb/rocksdb#18, which fix
rare edge cases in which keys could go missing if a range deletion
spanned SSTs in the wrong way.

Release note: None
craig bot pushed a commit to cockroachdb/cockroach that referenced this pull request Oct 26, 2018
31700: c-deps: bump RocksDB to pick up more range deletion fixes r=petermattis a=benesch

Picks up cockroachdb/rocksdb#17 and cockroachdb/rocksdb#18, which fix a rare edge case in which
keys could go missing if a range deletion spanned SSTs in the wrong way.

Release note: None

Co-authored-by: Nikhil Benesch <[email protected]>
petermattis pushed a commit to petermattis/cockroach that referenced this pull request Oct 31, 2018
Picks up cockroachdb/rocksdb#17 and cockroachdb/rocksdb#18, which fix
rare edge cases in which keys could go missing if a range deletion
spanned SSTs in the wrong way.

Release note: None
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants