[jira] [Comment Edited] (CASSANDRA-15459) Short read protection doesn't work on group-by queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17171622#comment-17171622
]
Caleb Rackliffe edited comment on CASSANDRA-15459 at 8/5/20, 5:03 PM:
--
+1 on both 3.11 and trunk PRs (and the decision to discard the Python dtest PR)
Especially w/ the trunk patch, there are some nice simplifications/readability
improvements.
Might want to run the unit tests one more time to account for CASSANDRA-15872
and CASSANDRA-15677.
was (Author: maedhroz):
+1 on both 3.11 and trunk PRs (and the decision to discard the Python dtest PR)
Especially w/ the trunk patch, there are some nice simplifications/readability
improvements.
Might want to run the unit tests one more time to account for CASSANDRA-15872.
> Short read protection doesn't work on group-by queries
> --
>
> Key: CASSANDRA-15459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15459
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: correctness
> Fix For: 3.11.x, 4.0-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> [DTest to
> reproduce|https://github.com/apache/cassandra-dtest/compare/master...jasonstack:srp_group_by_trunk?expand=1]:
> it affects all versions..
> {code}
> In a two-node cluster with RF = 2
> Execute only on Node1:
> * Insert pk=1 and ck=1 with timestamp 9
> * Delete pk=0 and ck=0 with timestamp 10
> * Insert pk=2 and ck=2 with timestamp 9
> Execute only on Node2:
> * Delete pk=1 and ck=1 with timestamp 10
> * Insert pk=0 and ck=0 with timestamp 9
> * Delete pk=2 and ck=2 with timestamp 10
> Query: "SELECT pk, c FROM %s GROUP BY pk LIMIT 1"
> * Expect no live data, but got [0, 0]
> {code}
> Note: for group-by queries, SRP should use "group counted" to calculate
> limits used for SRP query, rather than "row counted".
--
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] [Comment Edited] (CASSANDRA-15459) Short read protection doesn't work on group-by queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170976#comment-17170976
]
Caleb Rackliffe edited comment on CASSANDRA-15459 at 8/4/20, 6:30 PM:
--
[~adelapena] What's your opinion on whether the existing Python dtest would be
better as an in-JVM dtest? One thing that might be nice in this case is that we
could leave the trunk/4.0 version of the test in a simpler state, due to not
needing the Byteman injection to avoid blocking read-repair there. Also, I
think in-jvm tests would be able to run considerably faster, given they don't
need to stop and start nodes. (i.e. They can write only to specific nodes w/
{{executeInternal()}}.)
UPDATE: After reviewing, there might be a couple tests to add anyway, so I
suppose that adds to the argument for an in-JVM dtest.
was (Author: maedhroz):
[~adelapena] What's your opinion on whether the existing Python dtest would be
better as an in-JVM dtest? One thing that might be nice in this case is that we
could leave the trunk/4.0 version of the test in a simpler state, due to not
needing the Byteman injection to avoid blocking read-repair there. Also, I
think in-jvm tests would be able to run considerably faster, given they don't
need to stop and start nodes. (i.e. They can write only to specific nodes w/
{{executeInternal()}}.)
> Short read protection doesn't work on group-by queries
> --
>
> Key: CASSANDRA-15459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15459
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: correctness
> Fix For: 3.11.x, 4.0-beta
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> [DTest to
> reproduce|https://github.com/apache/cassandra-dtest/compare/master...jasonstack:srp_group_by_trunk?expand=1]:
> it affects all versions..
> {code}
> In a two-node cluster with RF = 2
> Execute only on Node1:
> * Insert pk=1 and ck=1 with timestamp 9
> * Delete pk=0 and ck=0 with timestamp 10
> * Insert pk=2 and ck=2 with timestamp 9
> Execute only on Node2:
> * Delete pk=1 and ck=1 with timestamp 10
> * Insert pk=0 and ck=0 with timestamp 9
> * Delete pk=2 and ck=2 with timestamp 10
> Query: "SELECT pk, c FROM %s GROUP BY pk LIMIT 1"
> * Expect no live data, but got [0, 0]
> {code}
> Note: for group-by queries, SRP should use "group counted" to calculate
> limits used for SRP query, rather than "row counted".
--
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] [Comment Edited] (CASSANDRA-15459) Short read protection doesn't work on group-by queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170976#comment-17170976
]
Caleb Rackliffe edited comment on CASSANDRA-15459 at 8/4/20, 5:30 PM:
--
[~adelapena] What's your opinion on whether the existing Python dtest would be
better as an in-JVM dtest? One thing that might be nice in this case is that we
could leave the trunk/4.0 version of the test in a simpler state, due to not
needing the Byteman injection to avoid blocking read-repair there. Also, I
think in-jvm tests would be able to run considerably faster, given they don't
need to stop and start nodes. (i.e. They can write only to specific nodes w/
{{executeInternal()}}.)
was (Author: maedhroz):
[~adelapena] What's your opinion on whether the existing Python dtest would be
better as an in-JVM dtest? One thing that might be nice in this case is that we
could leave the trunk/4.0 version of the test in a simpler state, due to not
needing the Byteman injection to avoid blocking read-repair there. Also, I
think in-jvm tests would be able to run considerably faster, given they don't
need to stop and start nodes. (i.e. They can write only to specific nodes w/
`executeInternal()`.)
> Short read protection doesn't work on group-by queries
> --
>
> Key: CASSANDRA-15459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15459
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: correctness
> Fix For: 3.11.x, 4.0-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [DTest to
> reproduce|https://github.com/apache/cassandra-dtest/compare/master...jasonstack:srp_group_by_trunk?expand=1]:
> it affects all versions..
> {code}
> In a two-node cluster with RF = 2
> Execute only on Node1:
> * Insert pk=1 and ck=1 with timestamp 9
> * Delete pk=0 and ck=0 with timestamp 10
> * Insert pk=2 and ck=2 with timestamp 9
> Execute only on Node2:
> * Delete pk=1 and ck=1 with timestamp 10
> * Insert pk=0 and ck=0 with timestamp 9
> * Delete pk=2 and ck=2 with timestamp 10
> Query: "SELECT pk, c FROM %s GROUP BY pk LIMIT 1"
> * Expect no live data, but got [0, 0]
> {code}
> Note: for group-by queries, SRP should use "group counted" to calculate
> limits used for SRP query, rather than "row counted".
--
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
