-
Notifications
You must be signed in to change notification settings - Fork 72
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
memtable_list: do not roll back memtable flush on CF drop #144
Comments
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
to introduce cf drop, use flag --clear_column_family_one_in . |
The white box is failing. Verification failed for column family 0 key 0000000000038053000000000000004F000000000000003B0000000000000009000000000000004F000000000000003E787878787878 (1638432): Unexpected value found my command: |
Thanks! Can you also post the |
Sure. BTW, the black box failed as well - for the same reason: Whitebox Blackbox |
Pretty sure that it's unrelated to the change in this issue because you have |
@Yuval-Ariel - please run full cycle as it seams to be unrelated to this change |
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
QA passed on c6567a6 |
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
This is a continuation of #126 with changes that were missed there in case a CF drop was encountered after the flush was completed but before or during manifest write. Rolling back on CF drop is meaningless because a flush is not possible in that state, and the only path forwards is for the memtables to be freed shortly afterwards, so making them available for flush again is useless at best. Additionally, this might be needed for the WriteBufferManager changes in in the future for triggering flushes based on immutable memory as well, and rolling back flushes causes the memtable memory to become ready for flush again for a brief period of time until it is dropped, which might wrongly affect the WBM decisions. Finally, the code installs a new version even if no changes are made. This is unnecessary and as such that part is moved into the version-mutating code path only. This PR also adds two regression tests, so we could rely on rollback not being performed on CF drop.
When installing memtable flush results, if the flush was unsuccessful (due to an error during the flush or the manifest write) or if the CF was dropped, the memtable is rolled back into a flushable state. However, this is unnecessary since it reactivates the pending flush flag on the relevant CF even though no flush can take place after CF drop, and as in #126 it also causes an issue for the upcoming improvements to the WriteBufferManager immutable memory tracking (#113) because it marks the memtable memory as ready for flush again for a short period before finally getting freed when the memtable is dropped during the destruction of the dropped CF (and this might upset the WBM behaviour because in the future we plan to rely on the amount of memory that isn't already being flushed for triggering flushes rather than on the amount of mutable memory alone as is done today).
This is a continuation of #126 (I simply missed this rollback), and since the rollback only marks the memtable as ready for flush again and clears related flush state, there's no harm in skipping it and just letting the memtable drop in that state.
The text was updated successfully, but these errors were encountered: