[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362830#comment-15362830 ] Benedict commented on CASSANDRA-11944: -- +1 > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360927#comment-15360927 ] Marcus Eriksson commented on CASSANDRA-11944: - ping on this [~benedict] > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327442#comment-15327442 ] Marcus Eriksson commented on CASSANDRA-11944: - pushed a new commit with method renames to the branch above, and triggered new cassci builds > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322365#comment-15322365 ] Benedict commented on CASSANDRA-11944: -- Probably - the earlier commits seemed to be for the other ticket. Thanks. I'll have a proper read of it later, but I would suggest renaming the methods to include the now implicit SSTableSet.LIVE, so it's still minimally front-and-centre when the functionality is used, by perhaps renaming select to selectLive, and sstablesInBounds to, perhaps, inBoundsLive(SSTables)? > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322357#comment-15322357
]
Marcus Eriksson commented on CASSANDRA-11944:
-
Maybe you were looking at the wrong commit? I have rebased and squashed
[here|https://github.com/krummas/cassandra/commits/marcuse/intervaltreesstableset]
{code}
-public Collection getOverlappingSSTables(SSTableSet
sstableSet, Iterable sstables)
+public Collection
getOverlappingSSTables(Iterable sstables)
{code}
> sstablesInBounds might not actually give all sstables within the bounds due
> to having start positions moved in sstables
> ---
>
> Key: CASSANDRA-11944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11944
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.x
>
>
> Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds
> for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In
> 3.0+ we state which SSTableSet we want when calling the method.
> Looks like the only issue this could cause is that we include a few too many
> sstables in compactions that we think contain only droppable tombstones
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1533#comment-1533 ] Benedict commented on CASSANDRA-11944: -- I'm a little confused by the patch and the JIRA comment - I don't see (in this branch) any removal of an option to provide an SSTableSet... > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312371#comment-15312371 ] Benedict commented on CASSANDRA-11944: -- Habits imply the future, at which date my life will hopefully not be so hectic. Currently mid-demolition and rebuild of my home, which is eating into my free and non-free time alike. > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312291#comment-15312291 ] Joshua McKenzie commented on CASSANDRA-11944: - No doubt - my hope was that the context of this would be similar enough to 11886 that the delta would be pretty small to add it on top. Not looking to make a habit of it. :) > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11944) sstablesInBounds might not actually give all sstables within the bounds due to having start positions moved in sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312213#comment-15312213 ] Benedict commented on CASSANDRA-11944: -- Life is very busy right now, but sure... > sstablesInBounds might not actually give all sstables within the bounds due > to having start positions moved in sstables > --- > > Key: CASSANDRA-11944 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11944 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 3.0.x, 3.x > > > Same problem as with CASSANDRA-11886 - if we try to fetch sstablesInBounds > for CANONICAL_SSTABLES, we can miss some actually overlapping sstables. In > 3.0+ we state which SSTableSet we want when calling the method. > Looks like the only issue this could cause is that we include a few too many > sstables in compactions that we think contain only droppable tombstones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
