[ https://issues.apache.org/jira/browse/CASSANDRA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700761#comment-16700761 ]
Benedict commented on CASSANDRA-14912: -------------------------------------- I _think_ the easiest fix for preventing the exception is to simply return a RT bound where the {{ColumnDefinition}} is definitely complex? This might mean we return a RT that covers a non-existent column, but with your change we *should* filter that out. But if we don't, that's fine, it's only a best effort, and it won't actually cause us any problems. FWIW, I've tried this change to confirm it works [here|https://github.com/belliottsmith/cassandra/tree/14912-3.0-suggest]. > 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