[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16627453#comment-16627453
]
Sam Tunnicliffe commented on CASSANDRA-14766:
---------------------------------------------
+1
The fact that we're now resetting {{couldBeStartOfPartition}} in
{{clearState}}, which wasn't done before probably fixes an overlooked edge case
in CASSANDRA-13236. We greedily read the static row in
{{AbstractSSTableIterator}}'s constructor, where {{isFirst}}
({{couldBeStartOfPartition}} as was) would trigger the swapping in the presence
of the required tombstone. {{IndexState::setToBlock}} attempts to skip past the
static row if we end up iterating backward to block 0 so we don't re-read the
static row, but without resetting this flag it would only skip past the RT,
leaving the statics to be read next which would then hit the the error from
13236.
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
> --------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
