[
https://issues.apache.org/jira/browse/CASSANDRA-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14110905#comment-14110905
]
Sylvain Lebresne commented on CASSANDRA-7810:
---------------------------------------------
We don't really need the {{if (!(expired.contains(tombstone) && !isExpired))}}
check in {{RangeTombstone.tracker}}: if the new tombstone and the existing one
have the same "data" they are obligatory either both expired or none are (since
the RT data is its deletion times info). Other than that, we could avoid the
isExpired set by passing maxPurgeableTimestamp and gcBefore to the tombstone
tacker and simply having it skipping expired tombstone when writting the
"markers", but I don't mind too much so if you like it the way it is, lgtm.
> 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-7810-test-for-2.0.x.patch,
> 0001-track-gcable-tombstones-v2.patch, 0001-track-gcable-tombstones.patch,
> 0002-track-gcable-tombstones-for-2.0.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)
