-
Notifications
You must be signed in to change notification settings - Fork 92
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
Assume fast_tombstone_all is set when deleting data #174
Labels
enhancement
New feature or request
Comments
PR: #366 |
vasil-pashov
added a commit
that referenced
this issue
Jun 9, 2023
…ersion_chain (#366) Resolves #174 **Changes** * Remove all branches involving fast tombstone property assuming it's always true. * Fix a bug in follow version chain functionality. **Bug description** Up to now the code assumes that there are no active versions after a tombstone_all key and stops following the version chain after encountering a `tombstone_all` key type. This is not true when we use `prune_previous_versions`. Imagine the following calls: 1. Add version 0 for a symbol `sym` 2. Add version 1 for the symbol `sym` 3. Prune previous versions This would result in the following version chain: 0. `(key_type: tombstone_all, version_id: 0)` 1. `(key_type: version, version_id: 0)` 2. `(key_type: index, version_id: 1)` 3. `(key_type: version, version_id: 1)` 5. `(key_type: index, version_id 0)` Where we have a live version (version 1) after the `tombstone_all` key. The bug does not appear when using `write + prune` because in that case we first add the `tombstone_all` key and after that we write the new version. **Solution** In case there is `tombstone_all` key, in `VersionMapImpl::follow_version_chain` we need to keep track of the oldest index which was read and stop reading only if `tombstone_all_->version_id()` is greater or equal to the `version_id` of the oldest index. --------- Co-authored-by: Vasil Pashov <Vasil.Pashov@man.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When deleting data, either a
tombstone
or aTOMBSTONE_ALL
key will be written.Whilst we need to respect either key type when reading data (for backwards compatibility reasons), there is no longer any reason to not write
TOMBSTONE_ALL
keys.This change will require simplifying the flow for deleting data to remove any code branches that would execute should
fast_tombstone_all
be off.The text was updated successfully, but these errors were encountered: