cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Morishita (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5248) Fix timestamp-based tomstone removal logic
Date Wed, 13 Feb 2013 20:26:12 GMT


Yuki Morishita commented on CASSANDRA-5248:

Sorry, I was wrong. I just got confused. :(
You're right that the comparison should be opposite.

> Fix timestamp-based tomstone removal logic
> ------------------------------------------
>                 Key: CASSANDRA-5248
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.2.1
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 1.2.2
>         Attachments: 5248.txt
> Quoting the description of CASSANDRA-4671:
> {quote}
> In other words, we should force CompactionController.shouldPurge() to return true if
min_timestamp(non-compacted-overlapping-sstables) > max_timestamp(compacted-sstables)
> {quote}
> but somehow this was translating in the code to:
> {noformat}
> if (sstable.getBloomFilter().isPresent(key.key) && sstable.getMinTimestamp()
>= maxDeletionTimestamp)
>     return false;
> {noformat}
> which, well, is reversed.
> Attaching the trivial patch to fix. I note that we already had a test that catched this
(CompactionsTest.testDontPurgeAccidentaly), but that test was racy in that most of the time
the compaction was done in the same second than the removal done prior to that and thus the
compaction wasn't considering the tombstone gcable even though gcgrace was 0. I've already
pushed the addition of a 1 second delay to make sure the patch reliably catch this bug.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message