cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-7875) Prepared statements using dropped indexes are not handled correctly
Date Tue, 03 Mar 2015 02:21:05 GMT


Stefania updated CASSANDRA-7875:

[~thobbs] and [~iamaleksey], this can only be reproduced on 2.0. On 2.1 the statement is already
invalidated because of the changes introduced by CASSANDRA-7910.

The index name and type are part of the column definition and when the index is dropped the
column definition changes. Therefore, {{MigrationSubscriber.onUpdateColumnFamily}} is called,
which invalidates the prepared statement.

Here is the output of the dtest attached (which is just converted to a dtest):

Executing prepared statement with dropped index...
code=2200 [Invalid query] message="No secondary indexes on the restricted columns support
the provided operators: "

So unless we need to fix this in 2.0 we can close it, please confirm.

> Prepared statements using dropped indexes are not handled correctly
> -------------------------------------------------------------------
>                 Key: CASSANDRA-7875
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Stefania
>            Priority: Minor
>             Fix For: 2.1.4
>         Attachments:,
> When select statements are prepared, we verify that the column restrictions use indexes
(where necessary).  However, we don't perform a similar check when the statement is executed,
so it fails somewhere further down the line.  In this case, it hits an assertion:
> {noformat}
> java.lang.AssertionError: Sequential scan with filters is not supported (if you just
created an index, you need to wait for the creation to be propagated to all nodes before querying
> 	at org.apache.cassandra.db.filter.ExtendedFilter$WithClauses.getExtraFilter(
> 	at org.apache.cassandra.db.ColumnFamilyStore.filter(
> 	at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(
> 	at org.apache.cassandra.db.PagedRangeCommand.executeLocally(
> 	at org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(
> 	at org.apache.cassandra.service.StorageProxy$
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at
> {noformat}
> During execution, we should check that the indexes still exist and provide a better error
if they do not.

This message was sent by Atlassian JIRA

View raw message