You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whenever we perform check version, if the meta-data or format version have changed, we try and clear the old version subspace if the new meta-data doesn't store record versions:
This is done because if we change the meta-data from storing to not storing record versions, than we will never consult this subspace again, and so if we don't clear it out, we'll leave stale data around. Worse, this can actually could cause records to be associated with the wrong versions if:
A record is stored with a version
Version storage is turned off, but the version data not cleared
That record is updated (or the record is deleted and a new record is stored at the same primary key)
Version storage is turned back on
The record written in step 3 now will be associated with the version saved in step 1
Note that this is not a concern with the newer version format, where versions are stored next to the record, as in that case, the version is always read, even if the meta-data option to store records with versions is not enabled. (The option effectively controls whether or not versions are added by default, not whether they are stored and read at all, like it does in the old format version.)
We can reduce the number of range clears here by being more exact about when we issue this clear range. For example, we never need to clear this out on new stores (as the range is already empty), nor do we need to if the store was not using the old version subspace before the meta-data or format versions are updated. We also don't need to clear this out if the old meta-data did not store record versions, but that information is unfortunately not available during checkVersion, because it doesn't have a copy of the old meta-data (just the old meta-data version).
The text was updated successfully, but these errors were encountered:
…on space
This reduces the number of unnecessary clears issued during check version by being more precise about when the legacy version subspace is cleared. It will only clear the range now if (1) the store is not new and (2) the store header suggests that any versions in the old store would have been stored in the old space. It introduces a test that validates that the version is cleared if versions were stored in that old subspace and the meta-data is changed to so that versions are no longer stores. That test valdiates that there are fewer range clears now if the range doesn't have to be cleared, but other than that assert, the test asserts pass both before and after the main code changes.
This resolvesFoundationDB#1936.
Whenever we perform check version, if the meta-data or format version have changed, we try and clear the old version subspace if the new meta-data doesn't store record versions:
fdb-record-layer/fdb-record-layer-core/src/main/java/com/apple/foundationdb/record/provider/foundationdb/FDBRecordStore.java
Lines 3921 to 3928 in a5f98c4
This is done because if we change the meta-data from storing to not storing record versions, than we will never consult this subspace again, and so if we don't clear it out, we'll leave stale data around. Worse, this can actually could cause records to be associated with the wrong versions if:
Note that this is not a concern with the newer version format, where versions are stored next to the record, as in that case, the version is always read, even if the meta-data option to store records with versions is not enabled. (The option effectively controls whether or not versions are added by default, not whether they are stored and read at all, like it does in the old format version.)
We can reduce the number of range clears here by being more exact about when we issue this clear range. For example, we never need to clear this out on new stores (as the range is already empty), nor do we need to if the store was not using the old version subspace before the meta-data or format versions are updated. We also don't need to clear this out if the old meta-data did not store record versions, but that information is unfortunately not available during
checkVersion
, because it doesn't have a copy of the old meta-data (just the old meta-data version).The text was updated successfully, but these errors were encountered: