[
https://issues.apache.org/jira/browse/CASSANDRA-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930435#comment-17930435
]
Caleb Rackliffe edited comment on CASSANDRA-19007 at 2/25/25 8:12 PM:
----------------------------------------------------------------------
Posting another concrete repro for this issue that appears to only affect
non-index filtering. SAI appears to be fine here, since it reads the full
partition on a static column match, and that sends and empty row to RFP for the
deleted row.
{noformat}
@Test
public void testX()
{
CLUSTER.schemaChange(withKeyspace("CREATE TABLE %s.testX (pk0 bigint, ck0
varint, s0 double static, v0 smallint, PRIMARY KEY (pk0, ck0)) " +
"WITH CLUSTERING ORDER BY (ck0 ASC) AND
read_repair = 'NONE'"));
CLUSTER.get(1).executeInternal(withKeyspace("INSERT INTO %s.testX (pk0,
ck0, s0, v0) VALUES (4501397456309286501, 15, -1.3193545560974702E211, 21040 -
-9610) USING TIMESTAMP 100"));
CLUSTER.get(3).executeInternal(withKeyspace("INSERT INTO %s.testX (pk0,
ck0, s0, v0) VALUES (4501397456309286501, -105, 1.7367761333573752E182, -11057)
USING TIMESTAMP 102"));
CLUSTER.get(2).executeInternal(withKeyspace("UPDATE %s.testX USING
TIMESTAMP 109 SET s0=1.9091237391303867E-65 + 1.933263240798876E72, v0=5284
WHERE pk0 = 4501397456309286501 AND ck0 = 0"));
CLUSTER.get(3).executeInternal(withKeyspace("INSERT INTO %s.testX (pk0,
ck0, s0, v0) VALUES (4501397456309286501, 3462, 6.873915736748052E-204, 12172)
USING TIMESTAMP 122"));
// We should match on all 4 rows at this point:
String select = withKeyspace("SELECT pk0, ck0 FROM %s.testX WHERE pk0 =
4501397456309286501 AND s0 <= 3.9683118225728584E-104 ALLOW FILTERING");
assertEquals(4, CLUSTER.coordinator(2).execute(select, ALL).length);
// This should delete ck = 0, bringing us down to 3 matches:
CLUSTER.get(3).executeInternal(withKeyspace("DELETE FROM %s.testX USING
TIMESTAMP 135 WHERE pk0 = 4501397456309286501 AND ck0 = 0"));
assertEquals(3, CLUSTER.coordinator(2).execute(select, ALL).length);
// Caused by: java.lang.AssertionError: Unexpected rows found:
// pk0 | ck0 | s0 | v0
// 4501397456309286501 | 0 | 3.9683118225728584E-104 | 5284
//
// Expected:
// pk0 | ck0 | s0 | v0
// 4501397456309286501 | 3462 | 3.9683118225728584E-104 | 12172
// 4501397456309286501 | 15 | 3.9683118225728584E-104 | 30650
// 4501397456309286501 | -105 | 3.9683118225728584E-104 | -11057
}
{noformat}
was (Author: maedhroz):
Posting another concrete repro for this issue that appears to only affect
non-index filtering:
{noformat}
@Test
public void testX()
{
CLUSTER.schemaChange(withKeyspace("CREATE TABLE %s.testX (pk0 bigint, ck0
varint, s0 double static, v0 smallint, PRIMARY KEY (pk0, ck0)) " +
"WITH CLUSTERING ORDER BY (ck0 ASC) AND
read_repair = 'NONE'"));
CLUSTER.get(1).executeInternal(withKeyspace("INSERT INTO %s.testX (pk0,
ck0, s0, v0) VALUES (4501397456309286501, 15, -1.3193545560974702E211, 21040 -
-9610) USING TIMESTAMP 100"));
CLUSTER.get(3).executeInternal(withKeyspace("INSERT INTO %s.testX (pk0,
ck0, s0, v0) VALUES (4501397456309286501, -105, 1.7367761333573752E182, -11057)
USING TIMESTAMP 102"));
CLUSTER.get(2).executeInternal(withKeyspace("UPDATE %s.testX USING
TIMESTAMP 109 SET s0=1.9091237391303867E-65 + 1.933263240798876E72, v0=5284
WHERE pk0 = 4501397456309286501 AND ck0 = 0"));
CLUSTER.get(3).executeInternal(withKeyspace("INSERT INTO %s.testX (pk0,
ck0, s0, v0) VALUES (4501397456309286501, 3462, 6.873915736748052E-204, 12172)
USING TIMESTAMP 122"));
// We should match on all 4 rows at this point:
String select = withKeyspace("SELECT pk0, ck0 FROM %s.testX WHERE pk0 =
4501397456309286501 AND s0 <= 3.9683118225728584E-104 ALLOW FILTERING");
assertEquals(4, CLUSTER.coordinator(2).execute(select, ALL).length);
// This should delete ck = 0, bringing us down to 3 matches:
CLUSTER.get(3).executeInternal(withKeyspace("DELETE FROM %s.testX USING
TIMESTAMP 135 WHERE pk0 = 4501397456309286501 AND ck0 = 0"));
assertEquals(3, CLUSTER.coordinator(2).execute(select, ALL).length);
// Caused by: java.lang.AssertionError: Unexpected rows found:
// pk0 | ck0 | s0 | v0
// 4501397456309286501 | 0 | 3.9683118225728584E-104 | 5284
//
// Expected:
// pk0 | ck0 | s0 | v0
// 4501397456309286501 | 3462 | 3.9683118225728584E-104 | 12172
// 4501397456309286501 | 15 | 3.9683118225728584E-104 | 30650
// 4501397456309286501 | -105 | 3.9683118225728584E-104 | -11057
}
{noformat}
> Queries with multi-column replica-side filtering can miss rows
> --------------------------------------------------------------
>
> Key: CASSANDRA-19007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19007
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
> Reporter: Andres de la Peña
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{SELECT}} queries with multi-column replica-side filtering can miss rows if
> the filtered columns are spread across out-of-sync replicas. This dtest
> reproduces the issue:
> {code:java}
> @Test
> public void testMultiColumnReplicaSideFiltering() throws IOException
> {
> try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY
> KEY, a int, b int)"));
> // insert a split row
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a)
> VALUES (0, 1)"));
> cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b)
> VALUES (0, 2)"));
> String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b =
> 2 ALLOW FILTERING");
> Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
> assertRows(initialRows, row(0, 1, 2)); // not found!!
> }
> }
> {code}
> This edge case affects queries using {{ALLOW FILTERING}} or any index
> implementation.
> It affects all branches since multi-column replica-side filtering queries
> were introduced, long before 3.0.
> The protection mechanism added by CASSANDRA-8272/8273 won't deal with this
> case, since it only solves single-column conflicts where stale rows could
> resurrect. This bug however doesn't resurrect data, it can only miss rows
> while the replicas are out-of-sync.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
