[
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154262#comment-13154262
]
Nicolas Spiegelberg commented on HBASE-2856:
--------------------------------------------
Something to keep in mind: we have a version of this for our prod branch
running on some smaller test clusters, but not yet on our actual prod clusters
(since we committed it at the same time you did). Also, note that between
HFileV2 & this, there is no easy downgrade strategy after moving from 90 to 92.
I think that putting this in a 92 RC definitely means a extra testing effort.
However, it's been the last massive outstanding caveat for ACID semantics so it
makes sense for 92 inclusion. I'm sure that other companies consider this a
critical issue for their customers, so they would be up for accelerating this
testing effort ahead of our schedule. :)
> TestAcidGuarantee broken on trunk
> ----------------------------------
>
> Key: HBASE-2856
> URL: https://issues.apache.org/jira/browse/HBASE-2856
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.89.20100621
> Reporter: ryan rawson
> Assignee: Amitanand Aiyer
> Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 2856-0.92.txt, 2856-v2.txt, 2856-v3.txt, 2856-v4.txt,
> 2856-v5.txt, 2856-v6.txt, 2856-v7.txt, 2856-v8.txt,
> 2856-v9-all-inclusive.txt, acid.txt
>
>
> TestAcidGuarantee has a test whereby it attempts to read a number of columns
> from a row, and every so often the first column of N is different, when it
> should be the same. This is a bug deep inside the scanner whereby the first
> peek() of a row is done at time T then the rest of the read is done at T+1
> after a flush, thus the memstoreTS data is lost, and previously 'uncommitted'
> data becomes committed and flushed to disk.
> One possible solution is to introduce the memstoreTS (or similarly equivalent
> value) to the HFile thus allowing us to preserve read consistency past
> flushes. Another solution involves fixing the scanners so that peek() is not
> destructive (and thus might return different things at different times alas).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
