cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5079) Compaction deletes ExpiringColumns in Secondary Indexes
Date Fri, 21 Dec 2012 08:07:23 GMT


Sylvain Lebresne commented on CASSANDRA-5079:

Yeah. If you look at the patch, the '+' should be '-' and vice-versa. You probably did a {{git
diff patched HEAD}} instead of {{git diff HEAD patch}}. But anyway, that's ok, no harm done.
> Compaction deletes ExpiringColumns in Secondary Indexes
> -------------------------------------------------------
>                 Key: CASSANDRA-5079
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: amorton
>            Assignee: amorton
>             Fix For: 1.1.9, 1.2.0 rc2
>         Attachments: 5079.txt
> From this discussion
> CompactionManager.getDefaultGcBefore() set's the gc_before to be Integer.MAX_VALUE. 
> In the example all entries in the secondary index have a TTL. In PreCompactedRow.removeDeletedAndOldShards()
the CF is determined to have irrelevant data, the call to CFS.removeDeleted() results in the
ExpiringColumns being removed and the row is treated as empty. CompactionTask.execute() exits
at the {{if (!nni.hasNext())}} test, so the sstables are marked as compacted and soon deleted.

> In the example the localDeletionTime was Thu, 21 Mar 2013 08:25:22 GMT and should not
have been purged. 
> In the example when the first compaction on the secondary index runs the on disk data
for the index is deleted. The logs show a compaction starting and no associated "Compacted
to" message from that compaction thread. 
> The impact is incorrect results from secondary indexes queries.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message