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
Now that we have CanDeterministicallySingleDelete, we could at runtime decide to single delete instead of delete when performing a delete against a DB or an indexed batch. We'd need to create an iterator, seek to the key, and call CanDeterministicallySingleDelete.
In implementing this, I discovered that CanDeterministicallySingleDelete is flawed with obsolete bit masking. The obsolete bit masking may hide a DEL within a table that's made obsolete by higher-seqnum'd SET within the same table. If there's another SET within a lower level, the top-level Iterator will observe SET, SET and conclude that it's unsafe to single delete when it is indeed safe.
The above doesn't preclude using it within the metamorphic tests if we have an option to disable obsolete-bit masking on a per-Iterator level.
There's still a complication around MERGE keys. The current key may be the result of combining multiple merges, in which case SINGLEDEL is not deterministic. CanDeterministicallySingleDelete will need a way to observe whether the current iterator position is the result of merging.
Now that we have CanDeterministicallySingleDelete, we could at runtime decide to single delete instead of delete when performing a delete against a
DB
or an indexed batch. We'd need to create an iterator, seek to the key, and call CanDeterministicallySingleDelete.Related to #3107.
The text was updated successfully, but these errors were encountered: