[ 
https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144858#comment-15144858
 ] 

James Taylor commented on PHOENIX-2680:
---------------------------------------

[~janvanbesien] - Yes, I see it's not ideal for your situation - a kind of 
hybrid of client controlled (for drop) and HBase controlled timestamps (for 
stats). What about this work around, since you control when UPDATE STATISTICS 
is called when it's called manually:
- When you get ready to call UPDATE STATISTICS, check the current timestamp on 
the table over which you're updating stats.
- Open a new connection with a CURRENT_SCN of the {{table timestamp + 1}}.
- Run UPDATE STATISTICS through this new connection

In this way, the stats will still get updated and make their way over to the 
client, but you won't get the NewerTableAlreadyExistsException because you 
won't be updating stats at the current HBase server timestamp.

> stats table timestamp incorrectly used as table timestamp
> ---------------------------------------------------------
>
>                 Key: PHOENIX-2680
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2680
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.6.0
>            Reporter: Jan Van Besien
>         Attachments: PHOENIX-2680.patch
>
>
> I think there is a problem introduced by PHOENIX-1390 related to table 
> timestamps.
> We run into a situation where we are unable to drop a table due to a 
> NewerTableAlreadyExistsException. This table was created at a certain 
> timestamp in the past (say 2 years ago) and we try to drop it at a more 
> recent timestamp in the past (say 1 year ago).
> During the drop, the client timestamp (1 year ago) is compared with the table 
> timestamp. The table timestamp should be 2 years ago, but due to this 
> statement on line 856 in MetaDataEndpointImpl:
> {code}
> timeStamp = Math.max(timeStamp, stats.getTimestamp())
> {code}
> the timestamp of the table is set to the timestamp of the stats table, which 
> happens to be something much more recent.
> I think this is wrong?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to