[
https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149765#comment-15149765
]
Hudson commented on PHOENIX-2680:
---------------------------------
SUCCESS: Integrated in Phoenix-master #1141 (See
[https://builds.apache.org/job/Phoenix-master/1141/])
PHOENIX-2680 stats table timestamp incorrectly used as table timestamp
(jamestaylor: rev d8e5a73be52c798b525068382e0376cb2d79e372)
*
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/StatisticsCollector.java
*
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/UngroupedAggregateRegionObserver.java
> 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
> Assignee: James Taylor
> Fix For: 4.7.0
>
> Attachments: PHOENIX-2680.patch, 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)
