[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680126#comment-13680126
]
Feng Honghua commented on HBASE-8721:
-------------------------------------
[~sershe]/[~apurtell] The scenario is refined as below:
1>. put a kv with timestamp T0, and flush;
2>. delete that kv with timestamp T1, and flush;
3>. a major compact occurs [or not];
4>. put that kv again with timestamp T0;
5>. read that kv;
a). if a major compact occurs at step 3>, then step 5> will get the put written
at step 4>
b). if no major compact occurs at step 3>, then step 5> get nothing
I think this is a BUG.
And I also DON'T think the behaviour where deletes masks later puts with the
same ts is expected. In some real-world scenarios where timestamp is used NOT
with time semantic but as another ordinary dimension of the kv's coordinate,
user puts a kv, deletes it, and some time later puts that kv again, finds the
write succeeds but can't read it out. Current delete behaviour limits such
extended usage of timestamp dimension.
Do we accept this incorrect/buggy behaviour as is just because it exists not
fixed for a so long time?
> fix for bug that delete can mask puts that happened after the delete was
> entered
> --------------------------------------------------------------------------------
>
> Key: HBASE-8721
> URL: https://issues.apache.org/jira/browse/HBASE-8721
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Feng Honghua
> Attachments: HBASE-8721-0.94-V0.patch
>
>
> this fix aims for bug mentioned in http://hbase.apache.org/book.html 5.8.2.1:
> "Deletes mask puts, even puts that happened after the delete was entered.
> Remember that a delete writes a tombstone, which only disappears after then
> next major compaction has run. Suppose you do a delete of everything <= T.
> After this you do a new put with a timestamp <= T. This put, even if it
> happened after the delete, will be masked by the delete tombstone. Performing
> the put will not fail, but when you do a get you will notice the put did have
> no effect. It will start working again after the major compaction has run.
> These issues should not be a problem if you use always-increasing versions
> for new puts to a row. But they can occur even if you do not care about time:
> just do delete and put immediately after each other, and there is some chance
> they happen within the same millisecond."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
