[
https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Taylor updated PHOENIX-2680:
----------------------------------
Attachment: PHOENIX-2680.patch
[~janvanbesien] - one issue with my previous suggestion is that by holding the
timestamp back to the table timestamp is that you won't see any data updates
that are newer than this timestamp when stats are updated. Take a look at this
patch which consistently checks phoenix.stats.useCurrentTime both on manual
UPDATE STATISTICS calls as well as major compaction. The table timestamp will
still be set to the max timestamp found while traversing the data rows while
updating stats. Please let me know if this will solve the issue you're facing.
> 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, 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)
