cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7875) Prepared statements using dropped indexes are not handled correctly
Date Tue, 06 Jan 2015 17:46:35 GMT


Aleksey Yeschenko commented on CASSANDRA-7875:

As for this ticket, I'm not sure that just adding an extra runtime check is the way to go,
or sufficient.
Since this event (dropping an index) should be very rare in production, we should probably
just extend CASSANDRA-7910 logic here, and just invalidate the potentially affected statements.

> Prepared statements using dropped indexes are not handled correctly
> -------------------------------------------------------------------
>                 Key: CASSANDRA-7875
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Tyler Hobbs
>            Priority: Minor
>             Fix For: 2.1.3
>         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