[
https://issues.apache.org/jira/browse/CASSANDRA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700735#comment-16700735
]
Sam Tunnicliffe commented on CASSANDRA-14912:
---------------------------------------------
bq. So surely specifically checking the condition that causes the failure, i.e.
that we're building a tombstone with a non-complex column, is the robust
solution to preventing this unavailable data?
Do you mean changing {{decodeBound}} to do something like return null or a
special value in such cases and having its callers handle that? It can't throw
in situations like this or else we're no better off than we are currently as
the row containing the collection tombstone would still be unreadable.
> LegacyLayout errors on collection tombstones from dropped columns
> -----------------------------------------------------------------
>
> Key: CASSANDRA-14912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14912
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> When reading legacy sstables in 3.0, the dropped column records in table
> metadata are not checked when a collection tombstone is encountered. This
> means that if a collection column was dropped and a new column with the same
> name but a non-collection type subsequently added prior to upgrading to 3.0,
> reading any sstables containing the collection data will error. This includes
> reads done by upgradesstables, which makes recovery from this situation
> without losing data impossible. Scrub will clean the affected tables, but any
> valid data will also be discarded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
