[
https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205304#comment-14205304
]
Jeremiah Jordan commented on CASSANDRA-6434:
--------------------------------------------
I think we need to make sure we still have some kind of grace period for
tombstones. An extreme edge case here, but:
1. user insert Y at time 10.
2. Insert gets held up in coordinator or something.
3. User inserts delete for Y at time 11 to a different node.
4. Incremental repair happens.
5. compaction happens (dropping the tombstone) because it was repaired.
6. insert at time 10 comes through.
If you have a gcgs > timeout period the data from step 6 will be ignored
(though you probably want it even longer than the timeout, as client retries
with same old timestamp could happen). If you don't have gcgs, the data could
suddenly show up even though a delete went through.
So as much as I like the idea of just removing gc grace, I think we really need
to keep it as the minimum time tombstones will stay around. But we could make
the default 30 minutes or something if we have the repair aware tombstone
removal.
> 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.3.4#6332)
