[
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)
