[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006896#comment-16006896
]
Andrés de la Peña commented on CASSANDRA-8272:
----------------------------------------------
Indeed, both returning entries that were recently valid but aren't anymore and
checking if the custom expressions are still valid after reconcilliation is
something that should be done by index implementations. Also, some
implementations could not be able or even not be interested on doing so.
Regarding the {{LIMIT}} problem, the new {{DataLimits}} suggested by
[~slebresne] could be provided by a new method
{{Index#getPostIndexQueryLimits}}, similar to the existing
[{{Index#getPostIndexQueryFilter}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/Index.java#L341].
Alternatively, we might just disable the limits at
[{{ReadCommand#executeLocally}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ReadCommand.java#L371]
and
[{{DataResolver#resolve}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/DataResolver.java#L79]
for index queries, and let the indexes take care of restricting the limits at
search time. This way the index implementations wouldn't require to specify a
{{CustomExpression#isSatistiedBy}} implementation, they would discard the stale
entries with their post processor, which could also be used for other things,
like sorting.
> 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]
