hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Gray (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1792) [Regression] Cannot save timestamp in the future
Date Tue, 25 Aug 2009 19:07:59 GMT

    [ https://issues.apache.org/jira/browse/HBASE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747581#action_12747581

Jonathan Gray commented on HBASE-1792:

There was a number of long discussions related to this.  Unfortunately, I forgot where we
ended up.

We tried to keep certain axioms, like "deletes only apply to older storefiles", but manually
setting of stamps (future or past)  breaks that.  That means, if you modify stamps manually,
your Gets can have indeterminate behavior.

I'd be more than happy to remove the strictness here, and allow anything < Long.MAX_VALUE
(if equal, rewrite as now()), with a warning in Put that manually setting of stamp can cause
indeterminate behavior, especially in Gets.

In any case, I'd like to see a unit test that verifies the behavior that we do have.  There
is already a bit of it in o.a.h.h.c.TestClient, but there should be more, perhaps another
method or part of testVersions().  It should do insertions with past, present, future stamps,
in all different orders, with lots of flushing in between (all issues with stamps / indeterminate
behavior are related to multiple storefiles + memstore interaction).

If we can create a new test, with comments explaining what the behavior is, and all prior
tests still pass, then I'll be +1 on allowing future stamps.

Stack, Erik, any recollection on why it was left this way?

This should also not have an impact on META where determinate behavior of Gets is quite important.

> [Regression] Cannot save timestamp in the future
> ------------------------------------------------
>                 Key: HBASE-1792
>                 URL: https://issues.apache.org/jira/browse/HBASE-1792
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.0
>            Reporter: Jean-Daniel Cryans
> 0.20, compared to previous versions, doesn't let you save with a timestamp in the future
and will set it to current time without telling you. This is really bad for users upgrading
to 0.20 that were using those timestamps.
> Example:
>  hbase(main):004:0> put 'testtable', 'r1', 'f1:c1', 'val', 5373965335336911168
>  0 row(s) in 0.0070 seconds
>  hbase(main):005:0> scan 'testtable'
>  ROW                          COLUMN+CELL                                           
>   r1                          column=f1:c1, timestamp=1251223892010, value=val      
>  1 row(s) in 0.0380 seconds

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message