You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/06/09 16:04:07 UTC

[jira] Commented: (CASSANDRA-223) time-based slicing does not work correctly w/ "historial" memtables

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

Jonathan Ellis commented on CASSANDRA-223:
------------------------------------------

Thinking about it more, the current behavior is sort of reasonable if you assume that timestamp values are strictly increasing.  I prefer not to rely on this because it's impossible to sync clocks with perfect accuracy, but it's a reasonable optimization to make and consistent with the rest of Cassandra's design.

In this case though, clock sync problems can lead to permanently inconsistent behavior -- different queries will not agree on what data the node contains.

> time-based slicing does not work correctly w/ "historial" memtables
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-223
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-223
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>         Attachments: 223.patch
>
>
> TimeFilter assumes that it is done as soon as it finds a column stamped earlier than what it is filtering on, but when you have a group of "historical" memtables whose columns were written in an arbitrary order this is not a safe assumption.
> It is not even a safe assumption when dealing with a single memtable + sstable pair, as the attached new test shows.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.