Andres de la Peña created CASSANDRA-16307:
---------------------------------------------
Summary: GROUP BY queries with paging can return deleted data
Key: CASSANDRA-16307
URL: https://issues.apache.org/jira/browse/CASSANDRA-16307
Project: Cassandra
Issue Type: Bug
Components: Consistency/Coordination
Reporter: Andres de la Peña
{{GROUP BY}} queries using paging and CL>ONE/LOCAL_ONE. This dtest reproduces
the problem:
{code:java}
try (Cluster cluster = init(Cluster.create(2)))
{
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (pk int, ck int,
PRIMARY KEY (pk, ck))"));
ICoordinator coordinator = cluster.coordinator(1);
coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (0,
0)"), ConsistencyLevel.ALL);
coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (1,
1)"), ConsistencyLevel.ALL);
cluster.get(1).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=0
AND ck=0"));
cluster.get(2).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=1
AND ck=1"));
String query = withKeyspace("SELECT * FROM %s.t GROUP BY pk");
Iterator<Object[]> rows = coordinator.executeWithPaging(query,
ConsistencyLevel.ALL, 1);
assertRows(Iterators.toArray(rows, Object[].class));
}
{code}
Using a 2-node cluster and RF=2, the test inserts two partitions in both nodes.
Then it locally deletes each row in a separate node, so each node sees a
different partition alive, but reconciliation should produce no alive
partitions. However, a {{GROUP BY}} query using a page size of 1 wrongly
returns one of the rows.
This has been detected during CASSANDRA-16180, and it is probably related to
CASSANDRA-15459, which solved a similar problem for group-by queries with
limit, instead of paging.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
