[
https://issues.apache.org/jira/browse/HBASE-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596349#comment-13596349
]
Lars Hofhansl commented on HBASE-8028:
--------------------------------------
That's probably the reason. In 0.94 and before it simply could not be done (and
whoever pulled the sync outside of the rowlock just ignored this problem to get
the performance benefit).
When I made this MVCC aware/safe (HBASE-4583) in trunk I did not realize that
now this is principle fixable. If I had I would have made a stronger to remove
upsert completely and always create new versions (just as do for all other
operations).
So we should have this discussion again. In HBASE-4583 I have a radical patch
that does away with upsert at the expense of performance. The radical patch
would the solution you outline (i.e. to the same we do for puts: remove the
added KVs if the sync fails).
The sentiment was that we should do the less radical version, which has the
compromise of using upsert when VERSIONS=1.
> Append, Increment don't handle wal-sync exceptions correctly
> ------------------------------------------------------------
>
> Key: HBASE-8028
> URL: https://issues.apache.org/jira/browse/HBASE-8028
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.94.5
> Reporter: Himanshu Vashishtha
> Assignee: Himanshu Vashishtha
> Fix For: 0.95.0
>
>
> In case there is an exception while doing the log-sync, the memstore is not
> rollbacked, while the mvcc is _always_ forwarded to the writeentry created at
> the beginning of the operation. This may lead to scanners seeing results
> which are not synched to the fs.
--
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
