[jira] [Updated] (PHOENIX-2680) stats table timestamp incorrectly used as table timestamp

["Jan Van Besien (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Van Besien updated PHOENIX-2680:
------------------------------------
    Attachment: PHOENIX-2680.patch

Patch against master. Essentially I just removed the line which I think is wrong (and added an integration test), I don't know if I might have broken something else which depended on the table timestamp to be set to the timestamp from the stats table?

> 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)