incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From horschi <hors...@gmail.com>
Subject Re: repair, compaction, and tombstone rows
Date Sat, 03 Nov 2012 21:23:58 GMT
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
>

Mime
View raw message