[
https://issues.apache.org/jira/browse/CASSANDRA-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15938125#comment-15938125
]
Branimir Lambov commented on CASSANDRA-13340:
---------------------------------------------
I think this is correct but I find the terminology confusing. Previous block
[sometimes|https://github.com/pcmanus/cassandra/commit/75a0c57b3c130343dd8068e32ef096e3057191e9#diff-68d265d33b5303cd50645cb4a7eba569R309]
means the next we'll iterate to (previous on disk), [other
times|https://github.com/pcmanus/cassandra/commit/75a0c57b3c130343dd8068e32ef096e3057191e9#diff-68d265d33b5303cd50645cb4a7eba569R327]
the previous we iterated. I'd prefer a consistent meaning for these; it looks
like the new code is at odds with the previous convention on these, so the
meanings of {{hasPrevious/NextBlock}} need reversing. {{skipLast/First}} have
the same problem, I'd at least add {{IteratedItem}} to their names to add a
little clarity.
[{{canIncludeSliceStart/End}}|https://github.com/pcmanus/cassandra/commit/75a0c57b3c130343dd8068e32ef096e3057191e9#diff-68d265d33b5303cd50645cb4a7eba569R334]
appear to have exactly the opposite meaning of {{hasPrevious/NextBlock}}. I
can see {{loadFromDisk}} needs separate booleans for the difference in the
non-indexed case, but {{readCurrentBlock}} can do without the latter, can't it?
> Bugs handling range tombstones in the sstable iterators
> -------------------------------------------------------
>
> Key: CASSANDRA-13340
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13340
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Critical
> Fix For: 3.0.x, 3.11.x
>
>
> There is 2 bugs in the way sstable iterators handle range tombstones:
> # empty range tombstones can be returned due to a strict comparison that
> shouldn't be.
> # the sstable reversed iterator can actually return completely bogus results
> when range tombstones are spanning multiple index blocks.
> The 2 bugs are admittedly separate but as they both impact the same area of
> code and are both range tombstones related, I suggest just fixing both here
> (unless something really really mind).
> Marking the ticket critical mostly for the 2nd bug: it can truly make use
> return bad results on reverse queries.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
