cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8272) 2ndary indexes can return stale data
Date Mon, 15 May 2017 12:35:04 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message