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) Inconsistent behavior on Tombstones
Date Fri, 19 Feb 2016 20:55:18 GMT


Anubhav Kale commented on CASSANDRA-11166:

Any thoughts on this ?

> Inconsistent behavior on Tombstones
> -----------------------------------
>                 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