[
https://issues.apache.org/jira/browse/CASSANDRA-16986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419669#comment-17419669
]
Benjamin Lerer commented on CASSANDRA-16986:
--------------------------------------------
[~jmckenzie] In my opinion cleaning things is good. It prevents us from wasting
time on trying to understand some useless pieces of code or reaching some wrong
conclusions. The cassandra code base is confusing enough even without all those
useless things.
> DROP Table should not recycle active CommitLog segments
> -------------------------------------------------------
>
> Key: CASSANDRA-16986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16986
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Commit Log
> Reporter: Aleksandr Sorokoumov
> Assignee: Aleksandr Sorokoumov
> Priority: Normal
> Fix For: 4.x
>
>
> Right now, DROP TABLE recycles all active CL segments and explicitly marks
> intervals as clean for all dropping tables. I believe that this is not
> necessary.
> Recycling of CL segments was introduced in CASSANDRA-3578. Back then, it was
> necessary to recycle all active segments because:
> 1. CommitLog reused old segments after they were clean. This is no longer the
> case, I believe, since CASSANDRA-6809.
> 2. CommitLog segments must have been closed and recycled on {{DROP TABLE}} to
> avoid resurrecting data if a table with the same name is created. This was an
> issue because tables didn't have unique ids yet (CASSANDRA-5202).
> Given that {{DROP TABLE}} triggers flush, which in turn cleans CL intervals
> in Keyspace#unloadCF, I think that we can avoid the call to
> {{forceRecycleAll}} there.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
