Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of horschi@gmail.com designates
 209.85.219.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKkz8Q3rPqAsDWM=1ig5wwikE4CfDH6bzRjXsBwdu-Rv09D11Q@mail.gmail.com>
References: 
 <CAPmnz8HFzw2O2mobJsVUOivxgb7uPgtukDKoovEd18Ke7w-WGA@mail.gmail.com>
	<CAKkz8Q3esii50yGZXNVLddQp38cpCekSzqQ5A2+tMELzJ5nf9A@mail.gmail.com>
	<CALY91SO1mCpREfmz0gt=4OMwrYZZbk9S19V9hXLaR1YODmfkng@mail.gmail.com>
	<CAKkz8Q3rPqAsDWM=1ig5wwikE4CfDH6bzRjXsBwdu-Rv09D11Q@mail.gmail.com>
Date: Sat, 3 Nov 2012 22:23:58 +0100
Message-ID: 
 <CALY91SM08WXO93_3J8HuQT2Wo879Rhp+-+6_OfGJ2DjNfHkDZA@mail.gmail.com>
Subject: Re: repair, compaction, and tombstone rows
From: horschi <horschi@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=f46d04462f0ecc1fb004cd9ddeed

--f46d04462f0ecc1fb004cd9ddeed
Content-Type: text/plain; charset=ISO-8859-1

Sure, created CASSANDRA-4905. I understand that these tombstones will be
still streamed though. Thats fine with me.

Do you mind if I ask where you stand on making...
- ... ExpiringColumn not create any tombstones? Imo this could be safely
done if the columns TTL is >= gcgrace. That way it is ensured that repair
ran and any previous un-TTLed columns were overwritten.
- ... ExpiringColumn not add local timestamp to digest?

Cheers,
Christian


On Sat, Nov 3, 2012 at 8:37 PM, Sylvain Lebresne <sylvain@datastax.com>wrote:

> On Fri, Nov 2, 2012 at 10:46 AM, horschi <horschi@gmail.com> wrote:
> > might I ask why repair cannot simply ignore anything that is older than
> > gc-grace? (like Aaron proposed)
>
> Well, actually the merkle tree computation could probably ignore
> gcable tombstones without much problem, which might not be such a bad
> idea and would probably solve much of your problem. However, when we
> stream the ranges that needs to be repaired, we stream sub-part of the
> sstables without deserializing them, so we can't exclude the gcable
> tombstones in that phase (that is, it's a technical reason, but
> deserializing data would be inefficient). Meaning that if we won't
> guarantee that you won't ever stream gcable tombstones.
>
> But excluding gcable tombstones from the merkle-tree computation is a
> good idea. Would you mind opening a JIRA ticket?
>
> --
> Sylvain
>

--f46d04462f0ecc1fb004cd9ddeed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sure, created CASSANDRA-4905. I understand that these tombstones will be st=
ill streamed though. Thats fine with me.<br><br>Do you mind if I ask where =
you stand on making...<br>- ... ExpiringColumn not create any tombstones? I=
mo this could be safely done if the columns TTL is &gt;=3D gcgrace. That wa=
y it is ensured that repair ran and any previous un-TTLed columns were over=
written.<br>
- ... ExpiringColumn not add local timestamp to digest?<br><br>Cheers,<br>C=
hristian<br><br><br><div class=3D"gmail_quote">On Sat, Nov 3, 2012 at 8:37 =
PM, Sylvain Lebresne <span dir=3D"ltr">&lt;<a href=3D"mailto:sylvain@datast=
ax.com" target=3D"_blank">sylvain@datastax.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Nov 2, 2012 at 10:46 AM, horschi &lt=
;<a href=3D"mailto:horschi@gmail.com" target=3D"_blank">horschi@gmail.com</=
a>&gt; wrote:<br>

&gt; might I ask why repair cannot simply ignore anything that is older tha=
n<br>
&gt; gc-grace? (like Aaron proposed)<br>
<br>
Well, actually the merkle tree computation could probably ignore<br>
gcable tombstones without much problem, which might not be such a bad<br>
idea and would probably solve much of your problem. However, when we<br>
stream the ranges that needs to be repaired, we stream sub-part of the<br>
sstables without deserializing them, so we can&#39;t exclude the gcable<br>
tombstones in that phase (that is, it&#39;s a technical reason, but<br>
deserializing data would be inefficient). Meaning that if we won&#39;t<br>
guarantee that you won&#39;t ever stream gcable tombstones.<br>
<br>
But excluding gcable tombstones from the merkle-tree computation is a<br>
good idea. Would you mind opening a JIRA ticket?<br>
<br>
--<br>
Sylvain<br>
</blockquote></div><br>

--f46d04462f0ecc1fb004cd9ddeed--