[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16008026#comment-16008026
]
Sergio Bossa commented on CASSANDRA-8272:
-----------------------------------------
bq. I just want us to have the discussion around filtering in CASSANDRA-8273
to avoid mixing things up, but If we can agree on moving filtering server-side
there quickly, then I'm totally fine doing that and the indexing in a single
patch if we prefer.
I'm fine with moving filtering server side, and I'm fine with dealing with it
on either issues provided we eventually address CASSANDRA-8273 straight away.
bq. If you're making a general point [about API], then sure.
Yes, I'm making a general point. Also see below.
bq. we'd have to rely on the version exchanged through gossip in a way we never
have, so with risks associated
Alright, I don't have enough knowledge to provide a proper risk assessment on
my own, so I'm fine with the previously proposed "split" patch.
bq. I think we can and should make most things index agnostic here
Totally agree here, and that's what I meant when saying we should make it work
with all index implementations and devise APIs to leverage. I agree we should
move away from using {{Index#postProcessorFor}}, and I agree we should keep the
counting outside the index implementation (again, as it will be useful to all
index implementations), but I'll leave the actual implementation details to
[~adelapena] and discuss once we've got a first cut.
So here's my take away about how we should move forward:
1) Provide a first patch based on 3.11 to fix the coordinator side.
2) Provide a second patch based on trunk to fix both coordinator and replica
side (we could address this first, review, and backport the coordinator side
once in agreement).
3) Leave filtering to CASSANDRA-8273, which we'll address straight after (this
patch is getting quite meaty already and I'm not convinced it's indeed better
to separate the two issues).
Thoughts?
> 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]
