[
https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006449#comment-13006449
]
Sylvain Lebresne commented on CASSANDRA-2317:
---------------------------------------------
This is clearly not of big importance.
I however think that we should fix this for coherence sake. Tombstones have
side effects on client queries and tombstone collection too (it's not just an
internal detail). As such, we should make the behavior as coherent as possible.
That a deletion always has effect until the first compaction after gc_grace
would be more coherent that the current status quo. The fact that Jeffrey was
surprised and that we assume right away that it was a bug proves that, I think.
And the fix is actually fairly simple, even though my patch doesn't do it
justice. The first patch is really just a refactoring that I think should have
been done a long time ago. I'm happy to create a ticket for this specifically
if we prefer, but I just think it is stupid to not factor that code.
The second part of the patch is to put markedDeletedAt and localDeletionTime in
a common structure that we CAS for changes. Again, this is because right now I
think we have a race condition when updating those two values. That is, we
could end up with the markedDeleteAt of a given operation but the
localDeletionTime of another one. This could also be put on another ticket (I
just tend to be lazy so I've put everything here, sorry).
Once those are done, the fix for this specific ticket is really just the
maybeResetDeletionTime() function.
> Column family deletion time is not always reseted after gc_grace
> ----------------------------------------------------------------
>
> Key: CASSANDRA-2317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2317
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.5
>
> Attachments:
> 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch,
> 0002-Add-unit-test.patch,
> 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Follow up of CASSANDRA-2305.
> Reproducible (thanks to Jeffrey Wang) by:
> Create a CF with gc_grace_seconds = 0 and no row cache.
> Insert row X, col A with timestamp 0.
> Insert row X, col B with timestamp 2.
> Remove row X with timestamp 1 (expect col A to disappear, col B to stay).
> Wait 1 second.
> Force flush and compaction.
> Insert row X, col A with timestamp 0.
> Read row X, col A (see nothing).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
