[
https://issues.apache.org/jira/browse/CASSANDRA-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731715#action_12731715
]
Jonathan Ellis commented on CASSANDRA-286:
------------------------------------------
patch 2 fixes the bug with tombstone handling in get_key_range that Evan
noticed in CASSANDRA-139
> slice offset breaks read repair
> -------------------------------
>
> Key: CASSANDRA-286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-286
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Attachments:
> 0001-CASSANDRA-286-r-m-offset-from-slice-api-we-could-live.txt,
> 0002-fix-not-including-tombstone-only-keys-in-keyRange.txt
>
>
> [code]
> int liveColumns = 0;
> int limit = offset + count;
> for (IColumn column : reducedColumns)
> {
> if (liveColumns >= limit)
> break;
> if (!finish.isEmpty()
> && ((isAscending && column.name().compareTo(finish) > 0))
> || (!isAscending && column.name().compareTo(finish) < 0))
> break;
> if (!column.isMarkedForDelete())
> liveColumns++;
> if (liveColumns > offset)
> returnCF.addColumn(column);
> }
> [code]
> The problem is that for offset to return the correct "live" columns, it has
> to ignore tombstones it scans before the first live one post-offset.
> This means that instead of being corrected within a few ms of a read, a node
> can continue returning deleted data indefinitely (until the next anti-entropy
> pass).
> Coupled with offset's inherent inefficiency (see CASSANDRA-261) I think this
> means we should take it out and leave offset to be computed client-side
> (which, for datasets under which it was reasonable server-side, will still be
> reasonable).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
