[CASSANDRA-11166] Range tombstones not accounted in tracing/cfstats

• Type: Bug
• Status: Resolved
• Priority: Low
• Resolution: Duplicate
• Fix Version/s: 3.11.2, 4.0-alpha1, 4.0
• Component/s: Legacy/Observability
• Severity: Low
• Assignee: Unassigned
• Reporter: Anubhav Kale
• Created: 12/Feb/16 19:11
• Updated: 15/May/20 08:04
• Resolved: 03/Jul/18 07:11

Description

I noticed an inconsistent behavior on deletes. Not sure if it is intentional.

The summary is:

If a table is created with TTL or if rows are inserted in a table using TTL, when its time to expire the row, tombstone is generated (as expected) and cfstats, cqlsh tracing and sstable2json show it.

However, if one executes a delete from table query followed by a select *, neither cql tracing nor cfstats shows a tombstone being present. However, sstable2json shows a tombstone.

Is this situation treated differently on purpose ? In such a situation, does Cassandra not have to scan tombstones (seems odd) ?

Also as a data point, if one executes a delete <some-column> from table, cqlsh tracing, nodetool cfstats, and sstable2json all show a consistent result (tombstone being present).

As a end user, I'd assume that deleting a row either via TTL or explicitly should show me a tombstone. Is this expectation reasonable ? If not, can this behavior be clearly documented ?

Issue Links

• duplicates: CASSANDRA-8527 Account for range tombstones wherever we account for tombstones