[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027834#comment-16027834
]
Andrés de la Peña commented on CASSANDRA-8272:
----------------------------------------------
[Here|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:cc6b762714942e3470daff4b815d3c311f16d856]
I'm working on the patch for 3.11. The row filter-aware data limits is not yet
finished, thus there are several tests failing, but I think it could be useful
to give an idea of the approach:
* Index interface has a new {{Index#getIndexQueryFilter(RowFilter)}} method,
intended to return a row filter with only the expressions served by the index.
It has a default implementation that returns the opposite to the already
existent {{Index#getPostIndexQueryFilter}}.
* Unfortunately, SASI don't return results satisfying the row filter, because
{{LIKE}} operator implementation doesn't take into account tokenization. So for
now {{SASIIndex#getIndexQueryFilter}} returns an empty filter.
* Index interface has a new {{Index#customExpressionFor(CFMetaData,
ByteBuffer)}} method to provide a custom expression implementation. The default
implementation returns a {{CustomExpression}} which {{isSatisfiedBy}} method
returns always {{true}} to keep compatibility. {{RowFilter.CustomExpression}}
class is modified to be abstract, and it has a builder method that requests the
specific implementation to the target index.
* {{PartitionRangeReadCommand#postReconciliationProcessing}} has been moved to
{{ReadCommand#postReconciliationProcessing}}. Now it removes all the rows not
satisfying {{Index#getIndexQueryFilter}} before calling to
{{Index#postProcessorFor}}, and it is called by all read queries {{#execute}}
and {{#executeInternal}} methods implementations.
* {{DataLimits}} has a new method {{newCounter(int, boolean, RowFilter,
CFMetaData)}} that returns a new row filter-aware {{DataLimits.Counter}}. This
counter, which is a transformation, should include in the results (but not
count) all the rows that don't satisfy the row filter. So, when a row filter is
specified, {{DataLimits.Counter}} is a not stopping transformation because all
the rows not satisfying the filter shouldn't be filtered, although they are not
counted.
* Both {{DataResolver#resolve}} and {{ReadQuery#executeInternal}}
implementations apply a {{DataLimits.Counter}} transformation using the filter
provided by {{Index#getIndexQueryFilter}}.
* {{CustomIndexTest#coordinatorSideFilteringTest}} contains several tests using
a custom index implementation that uses pure coordinator-side filtering.
[~slebresne], is it in line with what you suggested? Any recommendation for the
row filter-aware {{DataLimits}}?
> 2ndary indexes can return stale data
> ------------------------------------
>
> Key: CASSANDRA-8272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8272
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Andrés de la Peña
> Fix For: 3.0.x
>
>
> When replica return 2ndary index results, it's possible for a single replica
> to return a stale result and that result will be sent back to the user,
> potentially failing the CL contract.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v text);
> CREATE INDEX ON test(v);
> INSERT INTO test(k, v) VALUES (0, 'foo');
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v = 'bar' WHERE k = 0;
> SELECT * FROM test WHERE v = 'foo';
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned (since
> C will return it and A or B will return nothing).
> A potential solution would be that when we read a tombstone in the index (and
> provided we make the index inherit the gcGrace of it's parent CF), instead of
> skipping that tombstone, we'd insert in the result a corresponding range
> tombstone.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
