cassandra-commits mailing list archives

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


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