[
https://issues.apache.org/jira/browse/CASSANDRA-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721799#comment-17721799
]
Marcus Eriksson edited comment on CASSANDRA-18507 at 5/11/23 2:22 PM:
----------------------------------------------------------------------
+1 on the patch, very nice catch
pushed an alternative/additional test here:
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0
but the existing test is fine as well I think (though we might have a general
problem running tests with java11 on macos?)
running cci:
https://app.circleci.com/pipelines/github/krummas/cassandra/868/workflows/0ab45cff-4d06-4f25-ba55-e19a8dcb1ad2
https://app.circleci.com/pipelines/github/krummas/cassandra/869/workflows/a7502533-0524-4669-b450-a8bd3897cb34
was (Author: krummas):
+1 on the patch, very nice catch
pushed an alternative/additional test here:
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.1
https://github.com/krummas/cassandra/tree/CASSANDRA-18507-4.0
but the existing test is fine as well I think (though we might have a general
problem running tests with java11 on macos?)
running cci:
https://app.circleci.com/pipelines/github/krummas/cassandra/868/workflows/0ab45cff-4d06-4f25-ba55-e19a8dcb1ad2
https://app.circleci.com/pipelines/github/krummas/cassandra/867/workflows/bcb1a019-8576-46cb-8e97-b900c31e27ee
> Partial compaction can resurrect deleted data
> ---------------------------------------------
>
> Key: CASSANDRA-18507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18507
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
> Reporter: Tobias Lindaaker
> Assignee: Tobias Lindaaker
> Priority: Normal
>
> If there isn't enough disk space available to compact all existing sstables,
> Cassandra will attempt to perform a partial compaction by removing sstables
> from the set of candidate sstables to be compacted, starting with the largest
> one. It is possible that the sstable removed from the set of sstables to
> compact contains data for which there are tombstones in another (more recent)
> sstable. Since the overlaps between sstables is computed when the
> {{CompactionController}} is created, and the {{CompactionController}} is
> created before the removal of any sstables from the set of sstables to be
> compacted this computed overlap will be outdated when checking which sstables
> are covered by certain tombstones. This leads to the faulty conclusion that
> the tombstones can be pruned during the compaction, causing the data to be
> resurrected.
> The issue is present in Cassandra 4.0 and 4.1. Cassandra 3.11 creates the
> {{CompactionController}} after the set of sstables to compact has been
> reduced, and is thus not affected. {{trunk}} does not appear to support
> partial compactions at all, but instead refuses to compact when the disk is
> full.
> This regression appears to have been introduced by CASSANDRA-13068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]