[
https://issues.apache.org/jira/browse/CASSANDRA-14874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680066#comment-16680066
]
Ariel Weisberg commented on CASSANDRA-14874:
--------------------------------------------
I was just talking about something similar with [~bdeggleston] last night.
Seems like there is a case for an über tombstone with no partition or
clustering. Truncate should also require CL responses from all ranges on the
ring. This tombstone could shadow any data from before the truncation. Removing
all the pre-truncate data could then be a background deletion process.
> Read repair can race with truncations
> -------------------------------------
>
> Key: CASSANDRA-14874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14874
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Sylvain Lebresne
> Priority: Minor
>
> While hint and commit log replay handle truncation alright, we don't have
> anything to prevent a read/read-repair to race with {{TRUNCATE}}. In other
> words, you can have a read reading some pre-truncation data, some truncation
> running and removing that data, and then some read-repair mutation from that
> previous read that resurrects some data that should have bene truncated.
> Probably not that common in practice, but can lead to seemingly random data
> surviving truncate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
