cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anubhav Kale (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11166) Range tombstones not accounted in tracing/cfstats
Date Mon, 22 Feb 2016 17:08:18 GMT


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:
>             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
> 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

View raw message