[
https://issues.apache.org/jira/browse/CASSANDRA-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-4816:
----------------------------------------
Attachment: 4816-2.txt
Ok, second attempt. Looking more closing it does seem that this is a problem
with the interaction of the mergeIterator and the SSTableScanner. Basically the
mergeIterator always needs to know what his "the next row" (during the reducing
phase). If that next row was the one that the reducer ended up returning, we
were fine (so with 1 sstable or if all sstables had the same rows, it was ok),
but otherwise it might end up using the QueryFilter before it should for our
get_paged_slice "hack".
Anyway, all that the mergeIterator needs during its reduction phase is to know
the next key. So attaching a patch that delay the use of the filter until the
row data is actually queried.
> Broken get_paged_slice
> -----------------------
>
> Key: CASSANDRA-4816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4816
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.1.6
> Reporter: Piotr Kołaczkowski
> Priority: Blocker
> Attachments: 4816-2.txt
>
>
> get_paged_slice doesn't reset the start column filter for the second returned
> row sometimes. So instead of getting a slice:
> row 0: <start_column>...<last_column_in_row>
> row 1: <first column in a row>...<last_column_in_row>
> row 2: <first column in a row>...
> you sometimes get:
> row 0: <start_column>...<last_column_in_row>
> row 1: <start_column>...<last_column_in_row>
> row 2: <first column in a row>...
--
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: http://www.atlassian.com/software/jira
