[
https://issues.apache.org/jira/browse/CASSANDRA-14874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680360#comment-16680360
]
Sylvain Lebresne commented on CASSANDRA-14874:
----------------------------------------------
bq. Seems like there is a case for an über tombstone with no partition or
clustering.
Well, that's kind of what I'd qualify as having truncate being timestamp based,
and that's a much bigger change to Truncate that just this problem. It does
likely make this problem much easier to solve, or at least easier to solve the
right way, but it still qualify as a rewrite of truncate, and one that would
likely not fully preserve existing behavior (typically, you wouldn't be able to
add data with pre-truncate timstamp after a truncate (unless we do something
rather funky), while this is possible today; and to be extra clear, I am not
arguing the current behavior is better, I'm just pointing out that this
wouldn't be a fully backward compatible change, and that's to be taken into
account)
In any case, I'm not opposed at all to consider that option in principle,
because I do think a timestamp-based truncate is likely an overall better fit
to C* and we should probably have done first to start with, but as this is
probably a bit longer term (and probably deserve its own ticket), I'll still
suggest that maybe the trivial solution I've hinted in my previous comment
might be a good stopgap option to make things behave predictably most of the
time.
> 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: [email protected]
For additional commands, e-mail: [email protected]
