[PHOENIX-1417] Table Timestamp wrongly updated to latest time causing table deletion fail

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Not A Problem
• Affects Version/s: 4.2.0, 3.2.0
• Assignee: Unassigned
• Reporter: Jeffrey Zhong
• Created: 07/Nov/14 02:21
• Updated: 24/Mar/17 10:43
• Resolved: 05/Dec/14 03:15

Description

When we run QueryIT test against a live cluster, it fails with following exception:

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)

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

                 statsHTable = ServerUtil.getHTableForCoprocessorScan(env, PhoenixDatabaseMetaData.SYSTEM_STATS_NAME);
                 stats = StatisticsUtil.readStatistics(statsHTable, physicalTableName.getBytes(), clientTimeStamp);
                 timeStamp = Math.max(timeStamp, stats.getTimestamp());

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.

table = buildTable(key, cacheKey, region, HConstants.LATEST_TIMESTAMP)

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.

Issue Links

• is related to: PHOENIX-3699 Test suite PhoenixSparkITTenantSpecific fails