Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 22 Aug 2014 18:38:12 +0000 (UTC)
From: "Yuki Morishita (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12735788.1408630596406.14968.1408732692090@arcas>
In-Reply-To: <JIRA.12735788.1408630596406@arcas>
References: <JIRA.12735788.1408630596406@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-7810) tombstones gc'd before
 being locally applied
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yuki Morishita edited comment on CASSANDRA-7810 at 8/22/14 6:37 PM:
--------------------------------------------------------------------

Confirmed.
When merging two SSTable, one with composite cell and the other with RangeTombstone, only RangeTombstone is removed from merged SSTable (with gc_grace=0).
I think there is something going on when comparing those two cell name when reducing.


was (Author: yukim):
Confirmed.
When merging two SSTable, one with composite cell and the other with RangeTombstone, only RangeTombstone is removed from merged SSTable.
I think there is something going on when comparing those two cell name when reducing.

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