[
https://issues.apache.org/jira/browse/CASSANDRA-14894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-14894:
-----------------------------------------
Component/s: (was: Legacy/Local Write-Read Paths)
Local/SSTable
> 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/SSTable
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Normal
> 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.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
