Unfortunately, removing out-of-date deletes can be hazardous in one case: if there are other updates on that same key within the same segment.
To illustrate, imagine a case where a key is used exactly twice: a PUT is applied, then a DELETE is immediately applied afterwards. These occur within the same segment. Since no future updates occur, these will never be compacted away. However, if the DELETE is older than the MAX_DELETE_AGE threshold, it could be purged -- exposing the PUT, which would suddenly be the most recent update.
We should either (1) not remove DELETE operations if there are preceding PUT operations in a segment, or (2) implement internal segment compaction.
Unfortunately, removing out-of-date deletes can be hazardous in one case: if there are other updates on that same key within the same segment.
To illustrate, imagine a case where a key is used exactly twice: a PUT is applied, then a DELETE is immediately applied afterwards. These occur within the same segment. Since no future updates occur, these will never be compacted away. However, if the DELETE is older than the MAX_DELETE_AGE threshold, it could be purged -- exposing the PUT, which would suddenly be the most recent update.
We should either (1) not remove DELETE operations if there are preceding PUT operations in a segment, or (2) implement internal segment compaction.