[ 
https://issues.apache.org/jira/browse/CASSANDRA-14894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston updated CASSANDRA-14894:
----------------------------------------
    Reviewer: Sam Tunnicliffe
      Status: Patch Available  (was: Open)

|[3.0|https://github.com/bdeggleston/cassandra/tree/14894-3.0]|[circle|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/cci%2F14894-3.0]|
|[3.11|https://github.com/bdeggleston/cassandra/tree/14894-3.11]|[circle|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/cci%2F14894-3.11]|
|[trunk|https://github.com/bdeggleston/cassandra/tree/14894-trunk]|[circle|https://circleci.com/gh/bdeggleston/workflows/cassandra/tree/cci%2F14894-trunk]|

I cheated and didn't actually fix RangeTombstoneList, but am just filtering 
them out in RowAndDeletionMergeIterator instead. Fixing RangeTombstoneList to 
correctly handle things was not at all trivial and would have risked 
introducing correctness bugs.

> 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

Reply via email to