[jira] [Commented] (CASSANDRA-11166) Range tombstones not accounted in tracing/cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-11166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15158531#comment-15158531 ] Sylvain Lebresne commented on CASSANDRA-11166: -- The tombstone warning is covered by CASSANDRA-8527 (long story short, we do need to account for them but we're not sure we want to do so in stable releases since this could be surprising to some and hasn't proved so far to be a huge issue). > 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 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)
[jira] [Commented] (CASSANDRA-11166) Range tombstones not accounted in tracing/cfstats
[ https://issues.apache.org/jira/browse/CASSANDRA-11166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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)
