[
https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144288#comment-15144288
]
Jan Van Besien commented on PHOENIX-2680:
-----------------------------------------
[~jamestaylor] - thanks for the suggestions. We are relying heavily on client
controlled timestamps. Dropping the table at the latest timestamp would break
some use cases (e.g. we want to be able to drop at timestamp x and recreate at
y whereby y > x but both x and y are in the past). Disabling statistics is also
not something I really want to do, so I focussed on your first suggestion.
The phoenix.stats.useCurrentTime setting seems to be what I need, and mostly
works as expected. However:
* it only seems to be used for background statistics updates (during
compaction). When issuing an UPDATE STATISTICS statement, it seems that the
client timestamp is used for data written in the STATS table. I still think it
is a bug that in such a situation, a client gets a
NewerTableAlreadyExistsException while actually there is no newer table, but
only the STATS table contains newer data about the table.
* it seems that the metadatacache is not automatically updated when statistics
are updated. Hence there are situations where my drop table might or might not
work, depending on whether the metadatacache is up to date or not.
> 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)
