[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16307: Fix Version/s: (was: 4.0-beta) (was: 3.11.x) 4.0-beta5 3.11.11 Source Control Link: https://github.com/apache/cassandra/commit/7cddbd40ce6b326df533fd6d3c4131ef70b3b068 Resolution: Fixed Status: Resolved (was: Ready to Commit) Thank you for the review! Committed to 3.11 with [f258ae67516d53752c8d1f0a2576d72471ed427f|https://github.com/apache/cassandra/commit/f258ae67516d53752c8d1f0a2576d72471ed427f] and merged up to [trunk|https://github.com/apache/cassandra/commit/7cddbd40ce6b326df533fd6d3c4131ef70b3b068]. > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.11, 4.0-beta5 > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16307: Status: Ready to Commit (was: Review In Progress) +1 LGTM too. > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16307: Reviewers: Benjamin Lerer, Sam Tunnicliffe (was: Benjamin Lerer, beobal, Sam Tunnicliffe) > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16307: Reviewers: Benjamin Lerer, beobal, Sam Tunnicliffe (was: Benjamin Lerer, beobal) Status: Review In Progress (was: Patch Available) > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16307: Status: Patch Available (was: Open) > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16307: Reviewers: Benjamin Lerer, beobal (was: Andres de la Peña, Caleb Rackliffe) > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16307: Status: Open (was: Patch Available) > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16307: Test and Documentation Plan: Tests included. Harry tests are under way. Status: Patch Available (was: Open) > 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 >Assignee: Alex Petrov >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16307: --- Fix Version/s: 4.0-beta 3.11.x > 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 >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 3.11.x, 4.0-beta > > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16307: Reviewers: Andres de la Peña, Caleb Rackliffe (was: Andres de la Peña) > 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 >Assignee: Benjamin Lerer >Priority: Normal > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16307: -- Reviewers: Andres de la Peña > 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 >Assignee: Benjamin Lerer >Priority: Normal > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16307: -- Since Version: 3.10 > 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 >Priority: Normal > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16307) GROUP BY queries with paging can return deleted data
[ https://issues.apache.org/jira/browse/CASSANDRA-16307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16307: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Consistency(12989) Complexity: Normal Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > 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 >Priority: Normal > > {{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 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org