[
https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
