[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16010420#comment-16010420
]
Sylvain Lebresne commented on CASSANDRA-8272:
---------------------------------------------
Looks good to me.
bq. for trunk, we could either remove the
{{Index#customExpressionFor(CFMetaData cfm, ByteBuffer value)}} implementation
or keep it as an ease for index implementations not interested in or able of
implementing the coordinator side part of this.
For what it's worth, I'd really remove it. The default we're providing is just
broken for any sensible index implementation, and have a default implementation
that is intrinsically broken is wrong. Sure, so far we haven't relied on that
implementation, and with this ticket we would rely on it in a particular case
only, but all this isn't very future proof. And there is no real cost to asking
custom index to implement it: worst case, they can just making it always return
true themselves if they so wish, but at least they do it while being plainly
aware that it's dodgy and could brake things in the future.
> 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]
