[
https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143004#comment-15143004
]
James Taylor commented on PHOENIX-2680:
---------------------------------------
[~janvanbesien] - This line is necessary as the stats are part of the table
metadata and this ensures that the metadata is sent over to the client when the
stats are updated. There are a couple of things you can try, though, if this is
causing a problem for you:
- set phoenix.stats.useCurrentTime on server side to false. See
https://phoenix.apache.org/tuning.html for more info on this parameter:
{code}
An advanced server-side parameter that if true causes the current time on the
server-side to be used as the timestamp of rows in the statistics table when
background tasks such as compactions or splits occur. If false, then the max
timestamp found while traversing the table over which statistics are being
collected is used as the timestamp. Unless your client is controlling the
timestamps while reading and writing data, this parameter should be left alone.
The default value is true.
{code}
- issue your DROP TABLE at the latest timestamp
- disable stats by setting phoenix.stats.guidepost.width to a very large value.
This will negatively affect performance, though.
> 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)
