[
https://issues.apache.org/jira/browse/CASSANDRA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700637#comment-16700637
]
Sam Tunnicliffe commented on CASSANDRA-14912:
---------------------------------------------
Adding the check to {{LegacyLayout::decodeBound}} seems reasonable as an extra
safety check, but it wouldn’t make a difference in this case as we’d then fetch
the dropped column definition and proceed as before to construct the bound. We
could also check that the dropped column def was a collection and throw if not,
but that’s a slightly different bug IMO.
The dropped time check is what's really required otherwise we don't properly
filter data from sstables written before the schema changes happened. Maybe I'm
misunderstanding what you mean here about it not being terribly robust, but
this is the mechanism by which we filter such atoms (or simple/complex columns)
in both the legacy and non-legacy cases. I agree that it’s not perfect wrt to
clock drift btw, just that it’s the only method we have AFAIK for handling
dropped columns.
> 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
