[
https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070067#comment-14070067
]
Marcus Eriksson commented on CASSANDRA-6434:
--------------------------------------------
Hmm yes, [~kohlisankalp]s approach of dropping tombstones immediately (if the
key is not in any other sstable) works during compaction since we never compact
repaired and unrepaired data together. When doing incremental repair we should
probably include all tombstones. It is during reads we need an actual value on
gcBefore.
bq. We could approximate it as max(repairtime) for any sstable that may contain
the key.
Unless I misunderstand your suggestion, I don't think that would work since
max(repairtime) is dependent on compaction - the resulting sstable gets the
worst case (oldest) repair time among the involved sstables, meaning different
nodes will disagree on when the last repair was done for a key.
I'll unlink CASSANDRA-5839 - it would not work looking up actual per-key repair
times during reads anyway. Lets use gcgs on unrepaired data until we always
mark sstables as repaired.
> Repair-aware gc grace period
> -----------------------------
>
> Key: CASSANDRA-6434
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6434
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: sankalp kohli
> Assignee: Marcus Eriksson
> Fix For: 3.0
>
>
> Since the reason for gcgs is to ensure that we don't purge tombstones until
> every replica has been notified, it's redundant in a world where we're
> tracking repair times per sstable (and repairing frequentily), i.e., a world
> where we default to incremental repair a la CASSANDRA-5351.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
