[
https://issues.apache.org/jira/browse/CASSANDRA-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16650286#comment-16650286
]
Sam Tunnicliffe commented on CASSANDRA-14823:
---------------------------------------------
I realised that I'd overlooked one additional aspect here: that a 2.1 has the
potential to have multiple repeated RTs following a block boundary. So I've
updated the test data generator to do that, though I could only figure out how
to do it via the compaction path. While I was at it, I changed the naming of
the test tables slightly from {{...\_compact\_...}} to {{...\_compacted\_...}}
to avoid potential confusion due to the existing test tables named that way to
indicate that they use {{COMPACT STORAGE}}.
[3.0 branch|https://github.com/beobal/cassandra/tree/14823-3.0]
[2.1 sstable
generator|https://github.com/beobal/cassandra/commit/420457c3192952206e07276be7c2edf86aa79a7e]
[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F14823-3.0]
> Legacy sstables with range tombstones spanning multiple index blocks create
> invalid bound sequences on 3.0+
> -----------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14823
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14823
> Project: Cassandra
> Issue Type: Bug
> Reporter: Blake Eggleston
> Assignee: Blake Eggleston
> Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> During upgrade from 2.1 to 3.0, reading old sstables in reverse order would
> generate invalid sequences of range tombstone bounds if their range
> tombstones spanned multiple column index blocks. The read fails in different
> ways depending on whether the 2.1 tables were produced by a flush or a
> compaction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
