cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Knighton (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-12792) delete with timestamp long.MAX_VALUE for the whole key creates tombstone that cannot be removed.
Date Fri, 04 Nov 2016 16:15:59 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-12792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636859#comment-15636859
] 

Joel Knighton edited comment on CASSANDRA-12792 at 11/4/16 4:15 PM:
--------------------------------------------------------------------

Good observation on the {{hasPurgeEvaluator}} flag. I'll remove that in my follow up patch.
I'll also try the lambda approach on 3.0+; I think you're right in valuing clarity on the
version going forward here. When doing that, I'll look for chances to reduce verbosity. It
does feel bigger than it needs to be.

I'm not sure I understand the {{hasMemtableCf}}/{{hasTimestamp}} distinction. The only place
that {{hasMemtableCf}} is used is dictating whether we return the {{AlwaysTruePurgeEvaluator}}
or a {{TimestampedPurgeEvaluator}}. In the case that the value of {{hasMemtableCF}} matters,
we already know that {{filteredSSTables}} is empty. This means that the current {{minTimestamp}}
when we start inspecting memtables is {{Long.MAX_VALUE}}. We would need to set {{hasTimestamp}}
whenever the partition's mintimestamp is less than or equal to this {{minTimestamp}}, since
we need a {{TimestampedPurgeEvaluator}} in the case where a value in the partition is timestamped
with {{Long.MAX_VALUE}}. Since any long value will be less than or equal to {{Long.MAX_VALUE}},
it seems like setting a flag whenever we take the minTimestamp from a partition in a memtable
reduces to setting a flag whenever we have a partition in a memtable. I'm probably misunderstanding
something here.


was (Author: jkni):
Good observation on the {{hasPurgeEvaluator}} flag. I'll remove that in my follow up patch.
I'll also try the lambda approach on 3.0+; I think you're right in valuing clarity on the
version going forward here.

I'm not sure I understand the {{hasMemtableCf}}/{{hasTimestamp}} distinction. The only place
that {{hasMemtableCf}} is used is dictating whether we return the {{AlwaysTruePurgeEvaluator}}
or a {{TimestampedPurgeEvaluator}}. In the case that the value of {{hasMemtableCF}} matters,
we already know that {{filteredSSTables}} is empty. This means that the current {{minTimestamp}}
when we start inspecting memtables is {{Long.MAX_VALUE}}. We would need to set {{hasTimestamp}}
whenever the partition's mintimestamp is less than or equal to this {{minTimestamp}}, since
we need a {{TimestampedPurgeEvaluator}} in the case where a value in the partition is timestamped
with {{Long.MAX_VALUE}}. Since any long value will be less than or equal to {{Long.MAX_VALUE}},
it seems like setting a flag whenever we take the minTimestamp from a partition in a memtable
reduces to setting a flag whenever we have a partition in a memtable. I'm probably misunderstanding
something here.

> delete with timestamp long.MAX_VALUE for the whole key creates tombstone that cannot
be removed. 
> -------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12792
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12792
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Compaction
>            Reporter: Ian Ilsley
>            Assignee: Joel Knighton
>
> In db/compaction/LazilyCompactedRow.java 
> we only check for  <  MaxPurgeableTimeStamp  
> eg:
> (this.maxRowTombstone.markedForDeleteAt < getMaxPurgeableTimestamp())
> this should probably be <= 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message