cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7810) tombstones gc'd before being locally applied
Date Tue, 26 Aug 2014 16:31:57 GMT

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

Mime
View raw message