From cfadb8b8d98fe616c976cf1f697d360276206b86 Mon Sep 17 00:00:00 2001 From: Tom Bentley Date: Thu, 9 Jul 2020 11:57:52 +0100 Subject: [PATCH] MINOR: Define the term tombstone, since it's used elsewhere in the docs (#3480) Reviewers: Manikumar Reddy --- docs/design.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design.html b/docs/design.html index 3745ab5457a..082e87ea713 100644 --- a/docs/design.html +++ b/docs/design.html @@ -508,7 +508,7 @@ the log, even if the message with that offset has been compacted away; in this case this position is indistinguishable from the next highest offset that does appear in the log. For example, in the picture above the offsets 36, 37, and 38 are all equivalent positions and a read beginning at any of these offsets would return a message set beginning with 38.

- Compaction also allows for deletes. A message with a key and a null payload will be treated as a delete from the log. This delete marker will cause any prior message with that key to be removed (as would any new + Compaction also allows for deletes. A message with a key and a null payload will be treated as a delete from the log. Such a record is sometimes referred to as a tombstone. This delete marker will cause any prior message with that key to be removed (as would any new message with that key), but delete markers are special in that they will themselves be cleaned out of the log after a period of time to free up space. The point in time at which deletes are no longer retained is marked as the "delete retention point" in the above diagram.