[
https://issues.apache.org/jira/browse/CASSANDRA-14894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-14894:
----------------------------------------
Status: Ready to Commit (was: Patch Available)
> RangeTombstoneList doesn't properly clean up mergeable or superseded rts in
> some cases
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14894
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Major
> Fix For: 3.0.18, 3.11.4, 4.0
>
>
> There are a few scenarios RangeTombstoneList doesn't handle correctly.
> If there are 2 overlapping range tombstones with identical timestamps, they
> should be merged. Instead, they're stored as 2 rts with congruent bounds and
> identical timestamps.
> If a range tombstone supersedes multiple sequential range tombstones, instead
> of removing them, they cause the superseding rt to be split into multiple rts
> with congruent bounds and identical timestamps.
> When converted to an UnfilteredRowIterator, these become extra boundary
> markers with the same timestamp on each side. Logically these are noops, but
> they do cause digest mismatches which will cause unneeded read repairs, and
> repair overstreaming (since they're also included in flushed sstables).
> Also, not sure if this is reachable in practice, but querying RTL with an
> empty slice that covers a range tombstone causes an rt to be returned with an
> empty slice. If reachable this might cause extra read repairs as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
