cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3100) Secondary index still does minor compacting after deleting index
Date Wed, 19 Oct 2011 15:45:11 GMT


Sylvain Lebresne commented on CASSANDRA-3100:

I agree with the cure being worse than the disease. I think it will piss off people when they
have to wait 2 hours for a simple column family update because a long compaction is running.
We should at least only grab the locks when the update drops an index. Even then are we sure
this is solving the problem at end? In 0.7, I'm not sure why not holding the flush/compaction
locks during the index drop would trigger what is described here. In particular, as long as
the schema change has succeed, a bootstrapping node shouldn't be trying to build a secondary
index that isn't there.

All this being said, I think we may have a legit bug in 1.0.0, since an update of column family
can drop an index which will call removeAllSSTables which doesn't work as expected if the
compaction lock is not hold. But this should be fixed by CASSANDRA-3116.
> Secondary index still does minor compacting after deleting index
> ----------------------------------------------------------------
>                 Key: CASSANDRA-3100
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: Jeremy Hanna
>            Assignee: Jonathan Ellis
>            Priority: Minor
>              Labels: compaction
>             Fix For: 0.7.10
>         Attachments: 3100.txt
> We deleted all of our secondary indexes.  A couple of days later I was watching compactionstats
on one of the nodes and it was in the process of minor compacting one of the deleted secondary
indexes.  I double checked the keyspace definitions on the CLI and there were no secondary
indexes defined.

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


View raw message