[jira] [Commented] (CASSANDRA-14008) RTs at index boundaries in 2.x sstables can create unexpected CQL row in 3.x

["Kurt Greaves (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-14008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248976#comment-16248976 ] 

Kurt Greaves commented on CASSANDRA-14008:
------------------------------------------

So this kind of sounds like an issue we've been investigating, but we've had trouble finding the clustering that's actually causing the problem. Do you have an example to reproduce, or even just an example row to compare with?

If it's the same problem we've found that in some cases after upgrade to 3.11 the SSTable containing the data will also be corrupt.

> RTs at index boundaries in 2.x sstables can create unexpected CQL row in 3.x
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-14008
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14008
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jeff Jirsa
>            Assignee: Jeff Jirsa
>              Labels: correctness
>             Fix For: 3.0.x, 3.11.x
>
>
> In 2.1/2.2, it is possible for a range tombstone that isn't a row deletion and isn't a complex deletion to appear between two cells with the same clustering. The 8099 legacy code incorrectly treats the two (non-RT) cells as two distinct CQL rows, despite having the same clustering prefix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org