-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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 assertion that compaction input files are freeed #13109
Conversation
@jowlyzhang has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Does trivial move not create new FileMetaData for files in the new level? |
Oh, that's a good point. It definitely should create a new FileMetaData when installing a new Version. So this assertion failure is not something specific to trivial move. It's as long as |
30b6760
to
41e7e96
Compare
@jowlyzhang has updated the pull request. You must reimport the pull request before landing. |
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
@jowlyzhang has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
41e7e96
to
c172c6c
Compare
@jowlyzhang has updated the pull request. You must reimport the pull request before landing. |
@jowlyzhang has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@jowlyzhang merged this pull request in 8089eae. |
This assertion could fail if the compaction input files were successfully trivially moved. On re-locking db mutex after successful
LogAndApply
, those files could have been picked up again by some other compactions. And the assertion will fail.Example failure: P1669529213