[jira] [Comment Edited] (CASSANDRA-8558) deleted row still can be selected out

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

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

Benedict edited comment on CASSANDRA-8558 at 1/6/15 12:12 PM:
--------------------------------------------------------------

This is nothing to do with either change as far as I can tell. Somewhere inbetween those two changes something else was presumably broken, that is unrelated to either of them. It's possible that it was broken before either, in fact. Somewhere amongst them we changed drop behaviour to introduce flushing of dirty tables, and this flushing causes the problem. In fact we probably have a much worse problem than this appears.

I can illicit this behaviour with a simple call to nodetool flush. The deletion records are flushed to disk, and appear in their respective sstables, but are not being returned by the IndexedSliceReader that queries them. A new test to find this behaviour would be simpler: 

CREATE  KEYSPACE space1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
CREATE  TABLE space1.table1(a int, b int, c text,primary key(a,b));
INSERT INTO space1.table1(a,b,c) VALUES(1,1,'1');
// nodetool flush
DELETE FROM space1.table1 where a=1 and b=1;
// nodetool flush
SELECT * FROM space1.table1 where a=1 and b=1;

This is much more fundamentally broken than this ticket suggests, but I'm probably not the best person to investigate, since it looks to be a problem with IndexedSliceReader. Hopefully a git bisect with the updated test will blame a suitable candidate next time around :)

(assuming it isn't somehow still my fault)


was (Author: benedict):
This is nothing to do with either change as far as I can tell. Somewhere inbetween those two changes something else was presumably broken, that is unrelated to either of them. It's possible that it was broken before either, in fact. Somewhere amongst them we changed drop behaviour to introduce flushing of dirty tables, and this flushing causes the problem. In fact we probably have a much worse problem than this appears.

I can illicit this behaviour with a simple call to nodetool flush. The deletion records are flushed to disk, and appear in their respective sstables, but are not being returned by the IndexedSliceReader that queries them. A new test to find this behaviour would be simpler: 

CREATE  KEYSPACE space1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
CREATE  TABLE space1.table1(a int, b int, c text,primary key(a,b));
INSERT INTO space1.table1(a,b,c) VALUES(1,1,'1');
// nodetool flush
DELETE FROM space1.table3 where a=1 and b=1;
// nodetool flush
SELECT * FROM space1.table3 where a=1 and b=1;

This is much more fundamentally broken than this ticket suggests, but I'm probably not the best person to investigate, since it looks to be a problem with IndexedSliceReader. Hopefully a git bisect with the updated test will blame a suitable candidate next time around :)

(assuming it isn't somehow still my fault)

> 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: Philip Thompson
>             Fix For: 2.1.3
>
>
> 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)