[
https://issues.apache.org/jira/browse/CASSANDRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922254#action_12922254
]
Jonathan Ellis commented on CASSANDRA-1585:
-------------------------------------------
Let's do this the simple way so we can roll rc1, then we can make it better for
0.7.1: move migrations onto CompactionManager, and use
Table.flusherLock.writelock to avoid problems there.
> Schema change with compaction race
> ----------------------------------
>
> Key: CASSANDRA-1585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1585
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Stu Hood
> Assignee: Gary Dusbabek
> Priority: Critical
> Fix For: 0.7.0
>
>
> We observed what appeared to be a race between an ongoing compaction and a
> system_drop_cf call. The destination SSTable of the compaction was not
> removed by the drop, so it remained in the data directory. Recreating a CF of
> the same name caused the SSTable to become active again (or to at least show
> in the gossiped load).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
