cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-2305) Tombstoned rows not purged after gcgraceseconds
Date Fri, 11 Mar 2011 10:25:59 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-2305:
----------------------------------------

    Attachment: 0002-Invalidate-row-cache-on-compaction-purge.patch
                0001-Compaction-test.patch

I think this is due to row cache. We do not invalidate the row cache when a row is fully collected
by compaction.

Jeffrey, can you confirm that you had some row cache enabled when doing your experiments ?

Attaching 2 patch against 0.7. The first one is a unit test showing the failure, the second
one is the fix.

> Tombstoned rows not purged after gcgraceseconds
> -----------------------------------------------
>
>                 Key: CASSANDRA-2305
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2305
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: Jeffrey Wang
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 0.7.4
>
>         Attachments: 0001-Compaction-test.patch, 0002-Invalidate-row-cache-on-compaction-purge.patch
>
>
> From email to list:
> I was wondering if this is the expected behavior of deletes (0.7.0). Let's say I have
a 1-node cluster with a single CF which has gc_grace_seconds = 0. The following sequence of
operations happens (in the given order):
> insert row X with timestamp T
> delete row X with timestamp T+1
> force flush + compaction
> insert row X with timestamp T
> My understanding is that the tombstone created by the delete (and row X) will disappear
with the flush + compaction which means the last insertion should show up. My experimentation,
however, suggests otherwise (the last insertion does not show up).
> I believe I have traced this to the fact that the markedForDeleteAt field on the ColumnFamily
does not get reset after a compaction (after gc_grace_seconds has passed); is this desirable?
I think it introduces an inconsistency in how tombstoned columns work versus tombstoned CFs.
Thanks.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message