cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergio Bossa (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8272) 2ndary indexes can return stale data
Date Fri, 12 May 2017 12:10:05 GMT

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message