[
https://issues.apache.org/jira/browse/PHOENIX-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201591#comment-14201591
]
James Taylor commented on PHOENIX-1417:
---------------------------------------
It'd be an improvement to have this phoenix.stats.useCurrentTime on a per table
basis as well. I don't think users would mix using current time and controlling
the timestamp on the same table, but I can imagine they'd want to have some
tables with one and some with the other. Want to file a JIRA for that?
Shouldn't impact table creation/deletion cases when this property is set to
true. You can still do a flashback query and see the table as it was before
(along with the stats then as well).
> Table Timestamp wrongly updated to latest time causing table deletion fail
> --------------------------------------------------------------------------
>
> Key: PHOENIX-1417
> URL: https://issues.apache.org/jira/browse/PHOENIX-1417
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.0.0, 4.2, 3.2
> Reporter: Jeffrey Zhong
> Priority: Critical
> Attachments: fix.patch
>
>
> When we run QueryIT test against a live cluster, it fails with following
> exception:
> {noformat}
> org.apache.phoenix.schema.TableAlreadyExistsException: ERROR 1013 (42M04):
> Table already exists. tableName=ATABLE_IDX
> at
> org.apache.phoenix.schema.MetaDataClient.createTableInternal(MetaDataClient.java:1536)
> at
> org.apache.phoenix.schema.MetaDataClient.createIndex(MetaDataClient.java:980)
> at
> org.apache.phoenix.compile.CreateIndexCompiler$1.execute(CreateIndexCompiler.java:95)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:260)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:252)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:250)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1037)
> at
> org.apache.phoenix.end2end.BaseQueryIT.initTable(BaseQueryIT.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> {noformat}
> I added some trace found the root cause is that
> MetaDataEndpointImpl#getTable() has following code where we reset a table's
> timestamp using stats.getTimestamp().
> {code}
> statsHTable = ServerUtil.getHTableForCoprocessorScan(env,
> PhoenixDatabaseMetaData.SYSTEM_STATS_NAME);
> stats = StatisticsUtil.readStatistics(statsHTable,
> physicalTableName.getBytes(), clientTimeStamp);
> timeStamp = Math.max(timeStamp, stats.getTimestamp());
> {code}
> Since we always use LATEST_TIMESTAMP as client time stamp to build table as
> following code, it causes a table timestamp bump and a client using old SCN
> won't able to delete the table created with old SCN.
> {code}
> table = buildTable(key, cacheKey, region, HConstants.LATEST_TIMESTAMP)
> {code}
> In summary, I don't think we should use stats.getTimestamp to update table
> timestamp because stats is not relating to a table's "version" data.
> [~jamestaylor] I think it's a critical issue for people using client time
> stamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
