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

storage/metamorphic: Add MVCC delete range using tombstone #83945

Merged
merged 1 commit into from
Jul 7, 2022

Conversation

itsbilal
Copy link
Member

@itsbilal itsbilal commented Jul 6, 2022

This change adds MVCCDeleteRangeUsingTombstone to the MVCC
metamorphic tests. MVCCDeleteRange had already existed in
this test suite, so this ended up being a relatively simple
addition.

One part of #82545, with possibly more parts to follow
as other MVCC-level operations are added that utilize
writer.{Put,Clear}{MVCC,Engine}RangeKey.

Release note: None.

@itsbilal itsbilal requested a review from erikgrinaker July 6, 2022 21:51
@itsbilal itsbilal requested a review from a team as a code owner July 6, 2022 21:51
@itsbilal itsbilal self-assigned this Jul 6, 2022
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Contributor

@erikgrinaker erikgrinaker left a comment

Choose a reason for hiding this comment

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

It's a bit unclear to me how these tests verify the correctness of operations. Are we only testing that they don't crash or error?

I think what we really need is a set of randomized tests that verify that MVCC operations (including iterators) give the expected results, since there are far more edge cases than we can reasonably cover with explicit test cases.

writer readWriterID
key roachpb.Key
endKey roachpb.Key
txn txnID
Copy link
Contributor

Choose a reason for hiding this comment

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

MVCC range tombstones can't be transactional, since we don't have ranged intents yet. Is this a required artifact of the test harness? If not, I think I'd prefer to avoid involving transactions.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch. I removed the transactional code; I figured we needed it in place to be able to fake latching in the operation generator, but turns out it's not necessary just yet.

@itsbilal
Copy link
Member Author

itsbilal commented Jul 7, 2022

It's a bit unclear to me how these tests verify the correctness of operations. Are we only testing that they don't crash or error?

It's basically a determinism test. We spin up Pebble instances with different options, throw in some random store restarts in and random other mvcc operations (including MVCC Puts, CPuts, Gets, iterators, etc) and ensure that the result of those operations is consistent across different runs and instances of Pebble with different options. If, say, a compaction is corrupting a key somewhere or is leading to lack of determinism or consistent results, it'd show up here.

Errors don't fail the test if every instance of Pebble returned the same error when the same set of operations is run.

Copy link
Contributor

@erikgrinaker erikgrinaker left a comment

Choose a reason for hiding this comment

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

Gotcha, thanks. Sounds like we're going to need some other test infrastructure for randomized correctness testing then. Will give it some thought.

This change adds MVCCDeleteRangeUsingTombstone to the MVCC
metamorphic tests. MVCCDeleteRange had already existed in
this test suite, so this ended up being a relatively simple
addition.

One part of cockroachdb#82545, with possibly more parts to follow
as other MVCC-level operations are added that utilize
`writer.{Put,Clear}{MVCC,Engine}RangeKey`.

Release note: None.
@itsbilal itsbilal force-pushed the mvcc-metamorphic-delete-range branch from ec8132b to 9901620 Compare July 7, 2022 15:47
Copy link
Collaborator

@nicktrav nicktrav left a comment

Choose a reason for hiding this comment

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

Nice! :lgtm:

Reviewed 3 of 3 files at r2, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @erikgrinaker)

@itsbilal
Copy link
Member Author

itsbilal commented Jul 7, 2022

TFTRs!

bors r=erikgrinaker

@craig
Copy link
Contributor

craig bot commented Jul 7, 2022

Build succeeded:

@craig craig bot merged commit 6b7082a into cockroachdb:master Jul 7, 2022
Copy link
Collaborator

@jbowens jbowens left a comment

Choose a reason for hiding this comment

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

To improve coverage, I'm wondering if we some runs should perform the delete range as a scan with point deletes, in order to test equivalence between MVCCDeleteRange and MVCC point deletes?

Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained

@erikgrinaker
Copy link
Contributor

To improve coverage, I'm wondering if we some runs should perform the delete range as a scan with point deletes, in order to test equivalence between MVCCDeleteRange and MVCC point deletes?

They're not equivalent e.g. to an MVCC iterator, which will see range tombstones rather than point tombstones. They're only equivalent to an MVCC scan/get without tombstones.

@jbowens
Copy link
Collaborator

jbowens commented Jul 8, 2022

Yeah, makes sense. I wonder if we'd get more value out of MVCC metamorphic tests that perform equivalent operations adding abstractions on top, when necessary. Varying Pebble options is great for surfacing bugs in Pebble, but it seems unlikely to surface new MVCC bugs.

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