[
https://issues.apache.org/jira/browse/CASSANDRA-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275644#comment-14275644
]
Tyler Hobbs commented on CASSANDRA-8558:
----------------------------------------
So, I may be missing something, but it seems like we still have a problem. A
range tombstone can start far enough before the slice start that it gets a
different index entry, in which case we won't ever see it. It seems like to
handle arbitrary range tombstones with the current on-disk format, we would
need to read every RT before the slice start to check for overlap. Normally,
for CQL3, this isn't a problem, because RTs only cover a row. But with slice
deletions in Thrift, we should be able to see this problem.
Am I missing something about how we handle this, [~slebresne]?
> deleted row still can be selected out
> -------------------------------------
>
> Key: CASSANDRA-8558
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8558
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 2.1.2
> java version "1.7.0_55"
> Reporter: zhaoyan
> Assignee: Sylvain Lebresne
> Priority: Blocker
> Fix For: 2.0.12, 2.1.3
>
> Attachments: 8558-v2_2.0.txt, 8558-v2_2.1.txt, 8558.txt
>
>
> first
> {code}CREATE KEYSPACE space1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE TABLE space1.table3(a int, b int, c text,primary key(a,b));
> CREATE KEYSPACE space2 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 3};{code}
> second
> {code}CREATE TABLE space2.table1(a int, b int, c int, primary key(a,b));
> CREATE TABLE space2.table2(a int, b int, c int, primary key(a,b));
> INSERT INTO space1.table3(a,b,c) VALUES(1,1,'1');
> drop table space2.table1;
> DELETE FROM space1.table3 where a=1 and b=1;
> drop table space2.table2;
> select * from space1.table3 where a=1 and b=1;{code}
> you will find that the row (a=1 and b=1) in space1.table3 is not deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
