[
https://issues.apache.org/jira/browse/CASSANDRA-11166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15156674#comment-15156674
]
Sylvain Lebresne commented on CASSANDRA-11166:
--
This is mostly a logging problem, namely that we don't log range tombstones in
the trace (and in cfstats). That is, when the row is deleted, it generates a
range tombstone while it generates cell tombstones with TTL, which is why it
shows up in tracing/cfstats in the latter case but not in the former.
It's something we certainly should fix (though at least in tracing we might
want to log RT separately) but it doesn't have other consequences than being
confusing when you look at traces/cfstats.
> Inconsistent behavior on Tombstones
> ---
>
> Key: CASSANDRA-11166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11166
> Project: Cassandra
> Issue Type: Bug
>Reporter: Anubhav Kale
>Priority: Minor
>
> 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 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 ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
