[
https://issues.apache.org/jira/browse/CASSANDRA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700470#comment-16700470
]
Benedict commented on CASSANDRA-14912:
--------------------------------------
I think this is related to CASSANDRA-14749; basically I didn't properly fix it
for a drop and re-add of different type.
Should a fix also go
[here|https://github.com/apache/cassandra/blob/06c55f779ae68de98cce531e0b78be5716849003/src/java/org/apache/cassandra/db/LegacyLayout.java#L217]?
We could simply check that the column definition is a collection, and perhaps
also (if we wanted to be super paranoid) that the type is compatible.
Checking the dropped time is also a great additional check, but it doesn't
necessarily seem as robust, given clock drift.
> 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
