[
https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618530#comment-14618530
]
Marcus Eriksson edited comment on CASSANDRA-6434 at 7/8/15 12:55 PM:
---------------------------------------------------------------------
patch here: https://github.com/krummas/cassandra/commits/marcuse/6434-trunk and
I'd like some initial feedback on the approach from [~slebresne] if possible
For compaction it is quite simple as we only ever compact repaired and
unrepaired separately, so either we can or we cannot drop the tombstones. What
makes it difficult is during reads, when we merge results from repaired and
unrepaired sstables.
The basic idea of the patch is that we make LivenessInfo and DeletionTime know
if they were read from a repaired or an unrepaired sstable, then we use that
information in TombstonePurgingPartitionIterator to decide if we can actually
drop a tombstone
was (Author: krummas):
patch here: https://github.com/krummas/cassandra/commits/marcuse/6434-trunk and
I'd like some initial feedback on the approach from [~slebresne] if possible
> 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 beta 1
>
>
> 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.3.4#6332)
