[jira] [Updated] (CASSANDRA-7875) Prepared statements using dropped indexes are not handled correctly

["Stefania (JIRA)" <ji...@apache.org>]

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

Stefania updated CASSANDRA-7875:
--------------------------------
    Attachment: prepared_statements_test.py

[~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 repro.py converted to a dtest):

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

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: https://issues.apache.org/jira/browse/CASSANDRA-7875
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Stefania
>            Priority: Minor
>             Fix For: 2.1.4
>
>         Attachments: prepared_statements_test.py, repro.py
>
>
> 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 it)
> 	at org.apache.cassandra.db.filter.ExtendedFilter$WithClauses.getExtraFilter(ExtendedFilter.java:259)
> 	at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:1759)
> 	at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1709)
> 	at org.apache.cassandra.db.PagedRangeCommand.executeLocally(PagedRangeCommand.java:119)
> 	at org.apache.cassandra.service.StorageProxy$LocalRangeSliceRunnable.runMayThrow(StorageProxy.java:1394)
> 	at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1936)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:724)
> {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
(v6.3.4#6332)