[
https://issues.apache.org/jira/browse/CASSANDRA-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-8558:
----------------------------------------
Attachment: 8558-v2_2.1.txt
8558-v2_2.0.txt
bq. If they insert a range tombstone that spans a non-singleton range, and
query a slice starting in the middle of that range...?
You're right. I looked at your previous comment and focused on the EOC thing
because that's something I've wanted (and forgot) to change for a long time,
but that's actually not the problem. It's inconsistent and I think we should
fix it at least in 2.1 but the fact it fixes the test above is incidental and a
slightly modified version of the test (including in the patch) exhibits the bug
of this ticket even with the EOC "fix". I was further lead astray by the fix
version: the underlying bug does affect 2.0 as well, it's just that particular
example that does not.
The problem is indeed that IndexSliceReader don't include those range
tombstones that does intersect with the queried slices but don't start within
said slice. Attaching v2 patches to fix that. The 2.0 patch is smaller because:
# 2.1 is a little bit more careful to not create cell objects for stuff it
doesn't need to and as a consequence require a bit more code.
# the 2.1 patch includes a unit test (a small variation on the test above but
such that the range tombstone starts strictly before the queried slice to avoid
having the EOC business shadow the important issue). 2.0 doesn't have CQLTester
so I'll push the dtest when this is committed.
# I've included the v1 fixes in the 2.1 patch because it's the right thing to
do. I've left 2.0 alone however since it's less inconsistent than 2.1 on that
point.
# For some reason the indexed case of SSTablesNamesIterator has the same
problem. 2.0 and the non-indexed case do the right thing however so it's an
oversight.
> 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.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)
