[jira] [Updated] (CASSANDRA-16431) Group By breaks range tombstone closer

2021-02-18 Thread Benjamin Lerer (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Lerer updated CASSANDRA-16431:
---
Fix Version/s: (was: 4.0-rc)
   4.0.x
   3.11.x

> Group By breaks range tombstone closer
> --
>
> Key: CASSANDRA-16431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16431
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Alex Petrov
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> This is caused by the same piece of GROUP BY code that has caused 
> CASSANDRA-16307: counting. Since we have to look one row ahead in order to 
> “finish” the group, we’ll check out the next row but will return null to 
> transformations (including RT closer one). RT Closer will not see the row 
> and, since the iterator is considered done, it’ll complain that that’s not 
> right.
> Similar result can be achieved without paging, but with LIMIT 1.
> Minimal repro:
> {code:java}
> try (Cluster cluster = init(builder().withNodes(1).start()))
> {
> cluster.schemaChange("CREATE TABLE 
> distributed_test_keyspace.table_5 " +
>  "(pk0 bigint,pk1 bigint,ck0 bigint,ck1 
> bigint, PRIMARY KEY ((pk0,pk1), ck0, ck1)) " +
>  "WITH  CLUSTERING ORDER BY (ck0 ASC,ck1 
> ASC);");
> long pk1 = 1;
> long pk2 = 1;
> cluster.coordinator(1).execute("DELETE FROM 
> distributed_test_keyspace.table_5 USING TIMESTAMP 10 WHERE pk0=? AND 
> pk1=? AND ck0>?;", ConsistencyLevel.QUORUM, pk1, pk2, 2L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 1L, 1L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 3L, 1L);
> cluster.coordinator(1).executeWithPaging("SELECT pk0,pk1,ck0,ck1 
> FROM distributed_test_keyspace.table_5 WHERE pk0=? AND pk1=? GROUP BY 
> pk0,pk1,ck0;",
>  ConsistencyLevel.QUORUM,
>  1,
>  pk1, pk2);
> }
> {code}



--
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-16431) Group By breaks range tombstone closer

2021-02-17 Thread Alex Petrov (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-16431:

Fix Version/s: 4.0-rc

> Group By breaks range tombstone closer
> --
>
> Key: CASSANDRA-16431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16431
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.0-rc
>
>
> This is caused by the same piece of GROUP BY code that has caused 
> CASSANDRA-16307: counting. Since we have to look one row ahead in order to 
> “finish” the group, we’ll check out the next row but will return null to 
> transformations (including RT closer one). RT Closer will not see the row 
> and, since the iterator is considered done, it’ll complain that that’s not 
> right.
> Similar result can be achieved without paging, but with LIMIT 1.
> Minimal repro:
> {code:java}
> try (Cluster cluster = init(builder().withNodes(1).start()))
> {
> cluster.schemaChange("CREATE TABLE 
> distributed_test_keyspace.table_5 " +
>  "(pk0 bigint,pk1 bigint,ck0 bigint,ck1 
> bigint, PRIMARY KEY ((pk0,pk1), ck0, ck1)) " +
>  "WITH  CLUSTERING ORDER BY (ck0 ASC,ck1 
> ASC);");
> long pk1 = 1;
> long pk2 = 1;
> cluster.coordinator(1).execute("DELETE FROM 
> distributed_test_keyspace.table_5 USING TIMESTAMP 10 WHERE pk0=? AND 
> pk1=? AND ck0>?;", ConsistencyLevel.QUORUM, pk1, pk2, 2L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 1L, 1L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 3L, 1L);
> cluster.coordinator(1).executeWithPaging("SELECT pk0,pk1,ck0,ck1 
> FROM distributed_test_keyspace.table_5 WHERE pk0=? AND pk1=? GROUP BY 
> pk0,pk1,ck0;",
>  ConsistencyLevel.QUORUM,
>  1,
>  pk1, pk2);
> }
> {code}



--
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-16431) Group By breaks range tombstone closer

2021-02-08 Thread Sam Tunnicliffe (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Tunnicliffe updated CASSANDRA-16431:

Reviewers: Sam Tunnicliffe

> Group By breaks range tombstone closer
> --
>
> Key: CASSANDRA-16431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16431
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> This is caused by the same piece of GROUP BY code that has caused 
> CASSANDRA-16307: counting. Since we have to look one row ahead in order to 
> “finish” the group, we’ll check out the next row but will return null to 
> transformations (including RT closer one). RT Closer will not see the row 
> and, since the iterator is considered done, it’ll complain that that’s not 
> right.
> Similar result can be achieved without paging, but with LIMIT 1.
> Minimal repro:
> {code:java}
> try (Cluster cluster = init(builder().withNodes(1).start()))
> {
> cluster.schemaChange("CREATE TABLE 
> distributed_test_keyspace.table_5 " +
>  "(pk0 bigint,pk1 bigint,ck0 bigint,ck1 
> bigint, PRIMARY KEY ((pk0,pk1), ck0, ck1)) " +
>  "WITH  CLUSTERING ORDER BY (ck0 ASC,ck1 
> ASC);");
> long pk1 = 1;
> long pk2 = 1;
> cluster.coordinator(1).execute("DELETE FROM 
> distributed_test_keyspace.table_5 USING TIMESTAMP 10 WHERE pk0=? AND 
> pk1=? AND ck0>?;", ConsistencyLevel.QUORUM, pk1, pk2, 2L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 1L, 1L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 3L, 1L);
> cluster.coordinator(1).executeWithPaging("SELECT pk0,pk1,ck0,ck1 
> FROM distributed_test_keyspace.table_5 WHERE pk0=? AND pk1=? GROUP BY 
> pk0,pk1,ck0;",
>  ConsistencyLevel.QUORUM,
>  1,
>  pk1, pk2);
> }
> {code}



--
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-16431) Group By breaks range tombstone closer

2021-02-08 Thread Alex Petrov (Jira) 


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-16431:

 Bug Category: Parent values: Availability(12983)Level 1 values: Response 
Crash(12991)
   Complexity: Challenging
  Component/s: Consistency/Coordination
Discovered By: Fuzz Test
 Severity: Critical
   Status: Open  (was: Triage Needed)

> Group By breaks range tombstone closer
> --
>
> Key: CASSANDRA-16431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16431
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> This is caused by the same piece of GROUP BY code that has caused 
> CASSANDRA-16307: counting. Since we have to look one row ahead in order to 
> “finish” the group, we’ll check out the next row but will return null to 
> transformations (including RT closer one). RT Closer will not see the row 
> and, since the iterator is considered done, it’ll complain that that’s not 
> right.
> Similar result can be achieved without paging, but with LIMIT 1.
> Minimal repro:
> {code:java}
> try (Cluster cluster = init(builder().withNodes(1).start()))
> {
> cluster.schemaChange("CREATE TABLE 
> distributed_test_keyspace.table_5 " +
>  "(pk0 bigint,pk1 bigint,ck0 bigint,ck1 
> bigint, PRIMARY KEY ((pk0,pk1), ck0, ck1)) " +
>  "WITH  CLUSTERING ORDER BY (ck0 ASC,ck1 
> ASC);");
> long pk1 = 1;
> long pk2 = 1;
> cluster.coordinator(1).execute("DELETE FROM 
> distributed_test_keyspace.table_5 USING TIMESTAMP 10 WHERE pk0=? AND 
> pk1=? AND ck0>?;", ConsistencyLevel.QUORUM, pk1, pk2, 2L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 1L, 1L);
> cluster.coordinator(1).execute("INSERT INTO 
> distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING 
> TIMESTAMP 11;", ConsistencyLevel.QUORUM, pk1, pk2, 3L, 1L);
> cluster.coordinator(1).executeWithPaging("SELECT pk0,pk1,ck0,ck1 
> FROM distributed_test_keyspace.table_5 WHERE pk0=? AND pk1=? GROUP BY 
> pk0,pk1,ck0;",
>  ConsistencyLevel.QUORUM,
>  1,
>  pk1, pk2);
> }
> {code}



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