[
https://issues.apache.org/jira/browse/CASSANDRA-11166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157290#comment-15157290
]
Anubhav Kale commented on CASSANDRA-11166:
------------------------------------------
Thanks for the update.
Based on the code in SliceQueryFilter (2.1.9 Tag) where the
TombstoneoverwhelmingException is thrown, it appears that range tombstones
don't contribute to this counting. Is this the expected behavior (seems wrong
to me) ? So, I am not sure if this is just a logging issue or has more
implications.
> Range tombstones not accounted in tracing/cfstats
> -------------------------------------------------
>
> 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 <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 ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
