[
https://issues.apache.org/jira/browse/CASSANDRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922059#action_12922059
]
Gary Dusbabek commented on CASSANDRA-1585:
------------------------------------------
Deletion is a problem too. The main problem is that there are 3 services that
all aim to modify files: compaction, flushing and schema mutations. Compaction
and flushing are independent, but schema mutation isn't (we don't want to flush
while files are being moved or deleted).
> 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: Minor
> 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.
