[ https://issues.apache.org/jira/browse/CASSANDRA-15805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111019#comment-17111019 ]
Sylvain Lebresne edited comment on CASSANDRA-15805 at 5/26/20, 9:42 AM: ------------------------------------------------------------------------ Thanks for the review. I addressed the comments, squash-cleaned, 'merged' into 3.11 and started CI (first try at https://ci-cassandra.apache.org, not sure how that will go). ||branch||CI|| | [3.0|https://github.com/pcmanus/cassandra/commits/C-15805-3.0] | [ci-cassandra #134|https://ci-cassandra.apache.org/job/Cassandra-devbranch/134/] | | [3.11|https://github.com/pcmanus/cassandra/commits/C-15805-3.11] | [ci-cassandra #135|https://ci-cassandra.apache.org/job/Cassandra-devbranch/135/] | was (Author: slebresne): Thanks for the review. I addressed the comments, squash-cleaned, 'merged' into 3.11 and started CI (first try at https://ci-cassandra.apache.org, not sure how that will go). ||branch||CI|| | [3.0|https://github.com/pcmanus/cassandra/commits/C-15805-3.0] | [ci-cassandra #131|https://ci-cassandra.apache.org/job/Cassandra-devbranch/131/] | | [3.11|https://github.com/pcmanus/cassandra/commits/C-15805-3.11] | [ci-cassandra #132|https://ci-cassandra.apache.org/job/Cassandra-devbranch/132/] | > Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones > interacts with collection tombstones > ------------------------------------------------------------------------------------------------------------------ > > Key: CASSANDRA-15805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15805 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination, Local/SSTable > Reporter: Sylvain Lebresne > Assignee: Sylvain Lebresne > Priority: Normal > Fix For: 3.0.x, 3.11.x > > > The legacy reading code ({{LegacyLayout}} and > {{UnfilteredDeserializer.OldFormatDeserializer}}) does not handle correctly > the case where a range tombstone covering multiple rows interacts with a > collection tombstone. > A simple example of this problem is if one runs on 2.X: > {noformat} > CREATE TABLE t ( > k int, > c1 text, > c2 text, > a text, > b set<text>, > c text, > PRIMARY KEY((k), c1, c2) > ); > // Delete all rows where c1 is 'A' > DELETE FROM t USING TIMESTAMP 1 WHERE k = 0 AND c1 = 'A'; > // Inserts a row covered by that previous range tombstone > INSERT INTO t(k, c1, c2, a, b, c) VALUES (0, 'A', 'X', 'foo', {'whatever'}, > 'bar') USING TIMESTAMP 2; > // Delete the collection of that previously inserted row > DELETE b FROM t USING TIMESTAMP 3 WHERE k = 0 AND c1 = 'A' and c2 = 'X'; > {noformat} > If the following is ran on 2.X (with everything either flushed in the same > table or compacted together), then this will result in the inserted row being > duplicated (one part containing the {{a}} column, the other the {{c}} one). > I will note that this is _not_ a duplicate of CASSANDRA-15789 and this > reproduce even with the fix to {{LegacyLayout}} of this ticket. That said, > the additional code added to CASSANDRA-15789 to force merging duplicated rows > if they are produced _will_ end up fixing this as a consequence (assuming > there is no variation of this problem that leads to other visible issues than > duplicated rows). That said, I "think" we'd still rather fix the source of > the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org