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

flush_job: do not roll back memtable flush on CF drop and DB shutdown (#126) #127

Conversation

isaac-io
Copy link
Contributor

@isaac-io isaac-io commented Aug 19, 2022

Rolling back in these cases is meaningless because the memtables will be
freed shortly afterwards, so making them available for flush again is useless
at best.

Additionally, in atomic flush, memtables that were successfully flushed
aren't rolled back if a CF is dropped or a DB shutdown was requested (the
shutdown case is the more relevant one for the comparison here because it
aborts the flush, whereas the in the CF drop case it's simply ignored at
flush result installation time). In this regard this change simply matches
the behaviour there.

Lastly, this might be needed for the WriteBufferManager changes in #113,
since we plan to use the information about memory that can be flushed 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.

Test plan: run make check as well as make crash_test.

@isaac-io isaac-io added the Upstreamable can be upstreamed to RocksDB label Aug 19, 2022
@isaac-io isaac-io self-assigned this Aug 19, 2022
@udi-speedb
Copy link
Contributor

@isaac-io: Did make check completed successfully on this branch?

@isaac-io
Copy link
Contributor Author

@isaac-io: Did make check completed successfully on this branch?

Yes. Both make check and make crash_test completed successfully.

…#126)

Rolling back in these cases is meaningless because the memtables will be
freed shortly afterwards, so making them available for flush again is useless
at best.

Additionally, in atomic flush, memtables that were successfully flushed
aren't rolled back if a CF is dropped or a DB shutdown was requested (the
shutdown case is the more relevant one for the comparison here because it
aborts the flush, whereas the in the CF drop case it's simply ignored at
flush result installation time). In this regard this change simply matches
the behaviour there.

Lastly, this might be needed for the WriteBufferManager changes in #113,
since we plan to use the information about memory that can be flushed 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.
@isaac-io isaac-io force-pushed the 126-flush_job-do-not-roll-back-memtable-flush-in-on-cf-drop-or-database-shutdown branch from c8f40e5 to 5ca8d30 Compare August 21, 2022 15:35
@isaac-io isaac-io merged commit 5c529bb into main Aug 21, 2022
@isaac-io isaac-io deleted the 126-flush_job-do-not-roll-back-memtable-flush-in-on-cf-drop-or-database-shutdown branch August 22, 2022 09:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Upstreamable can be upstreamed to RocksDB
Projects
None yet
Development

Successfully merging this pull request may close these issues.

flush_job: do not roll back memtable flush on CF drop or database shutdown
2 participants