[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16020827#comment-16020827
]
Sylvain Lebresne commented on CASSANDRA-8272:
---------------------------------------------
bq. Some index implementations could do faster local searches in the underlying
index structure if they know that they have to skip stale entries
Maybe, but again this is pushing more details to the index implementation in a
way that becomes a bit black box for us, and 1) I feel this make things more
complex overall and 2) I fear about this beating us back in the future. So even
if I was to do that optimization of moving filtering to the replica on CL.ONE,
I'd still prefer keeping it index-independent.
Don't get me wrong, this is largely personal opinion I'm expressing here. I
_prefer_ keeping things simpler, asking from custom index a behavior that is as
simple, consistent and as generic as possible (so with as little special case
as possible). As said above, I'm not convinced the amount of stale entries
we'll end up dealing with in practice will be really big (again, that's where
this mainly differs from CASSANDRA-8273 imo), so I can't shake the feeling that
all this would be premature optimization. Or to put it more bluntly, I'm ok
with the trade-off of removing a few hypothetical and edge case opportunity for
optimization from custom index implementations for the benefit of keeping our
code and the general custom index contract simpler and more maintainable.
Note that I'm distinguishing the two level of 1) moving the filtering
replica-side for CL.ONE and 2) actually pushing to the index implementation the
responsibility of said replica-side CL.ONE filtering. I do kind of feel both
are a bit premature optimizations as far as this ticket goes tbh, but I don't
mind 1) so much, while I'm a bit more wary of 2) for the reasons expressed
above.
> 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]
