phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Zhong (JIRA)" <>
Subject [jira] [Created] (PHOENIX-1417) Table Timestamp wrongly updated to latest time causing table deletion fail
Date Fri, 07 Nov 2014 02:22:33 GMT
Jeffrey Zhong created PHOENIX-1417:

             Summary: Table Timestamp wrongly updated to latest time causing table deletion
                 Key: PHOENIX-1417
             Project: Phoenix
          Issue Type: Bug
    Affects Versions: 5.0.0, 4.2, 3.2
            Reporter: Jeffrey Zhong
            Priority: Critical

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.
        at org.apache.phoenix.schema.MetaDataClient.createTableInternal(
        at org.apache.phoenix.schema.MetaDataClient.createIndex(
        at org.apache.phoenix.compile.CreateIndexCompiler$1.execute(
        at org.apache.phoenix.jdbc.PhoenixStatement$
        at org.apache.phoenix.jdbc.PhoenixStatement$
        at org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(
        at org.apache.phoenix.jdbc.PhoenixStatement.execute(
        at org.apache.phoenix.end2end.BaseQueryIT.initTable(
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(

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

This message was sent by Atlassian JIRA

View raw message