[
https://issues.apache.org/jira/browse/CASSANDRA-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845823#comment-13845823
]
Jonathan Ellis commented on CASSANDRA-6008:
-------------------------------------------
(Looking at the 2.0 patch)
- You're right that hasIrrelevantData is just checking for tombstones to purge
now... it used to check for cells shadowed by tombstones as well. Is it
another regression that it does not?
- Looks to me like dropping the shouldPurge check from LCR.write is a
regression -- shouldPurge is what says "we're sure there's no data in other
sstables that should be shadowed by this tombstone." Surprised we don't have a
test that catches that.
- I'm not actually sure where the bug is in the original code. I see that the
Reducer fix will result in correctly purging range tombstones now, but I don't
think that's the dropping-row-tombstones bug you referred to. The code in the
constructor is cleaner now but I don't see why the original didn't work as
intended.
> Getting 'This should never happen' error at startup due to sstables missing
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-6008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6008
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: John Carrino
> Assignee: Tyler Hobbs
> Fix For: 2.0.4
>
> Attachments: 6008-2.0-v1.patch, 6008-trunk-v1.patch
>
>
> Exception encountered during startup: "Unfinished compactions reference
> missing sstables. This should never happen since compactions are marked
> finished before we start removing the old sstables"
> This happens when sstables that have been compacted away are removed, but
> they still have entries in the system.compactions_in_progress table.
> Normally this should not happen because the entries in
> system.compactions_in_progress are deleted before the old sstables are
> deleted.
> However at startup recovery time, old sstables are deleted (NOT BEFORE they
> are removed from the compactions_in_progress table) and then after that is
> done it does a truncate using SystemKeyspace.discardCompactionsInProgress
> We ran into a case where the disk filled up and the node died and was bounced
> and then failed to truncate this table on startup, and then got stuck hitting
> this exception in ColumnFamilyStore.removeUnfinishedCompactionLeftovers.
> Maybe on startup we can delete from this table incrementally as we clean
> stuff up in the same way that compactions delete from this table before they
> delete old sstables.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
