[
https://issues.apache.org/jira/browse/CASSANDRA-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109132#comment-14109132
]
Sylvain Lebresne commented on CASSANDRA-7810:
---------------------------------------------
bq. Can you elaborate why?
I had missed your " this could break columnIndex building since we track
tombstones that are not stored". Still kind of feel that fixing the tombstone
tracker to not write on disk expired tombstones would be cleaner.
> tombstones gc'd before being locally applied
> --------------------------------------------
>
> Key: CASSANDRA-7810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7810
> Project: Cassandra
> Issue Type: Bug
> Environment: 2.1.0.rc6
> Reporter: Jonathan Halliday
> Assignee: Marcus Eriksson
> Fix For: 2.1.0
>
> Attachments: 0001-track-gcable-tombstones.patch,
> range_tombstone_test.py
>
>
> # single node environment
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1 };
> use test;
> create table foo (a int, b int, primary key(a,b));
> alter table foo with gc_grace_seconds = 0;
> insert into foo (a,b) values (1,2);
> select * from foo;
> -- one row returned. so far, so good.
> delete from foo where a=1 and b=2;
> select * from foo;
> -- 0 rows. still rainbows and kittens.
> bin/nodetool flush;
> bin/nodetool compact;
> select * from foo;
> a | b
> ---+---
> 1 | 2
> (1 rows)
> gahhh.
> looks like the tombstones were considered obsolete and thrown away before
> being applied to the compaction? gc_grace just means the interval after
> which they won't be available to remote nodes repair - they should still
> apply locally regardless (and do correctly in 2.0.9)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
