phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chinmay Kulkarni (Jira)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-5546) TASK_TS being set as HConstants.LATEST_TIMESTAMP in SYSTEM.TASK table
Date Fri, 25 Oct 2019 07:44:00 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chinmay Kulkarni updated PHOENIX-5546:
--------------------------------------
    Description: 
When we upsert DropChildViewTask entries into SYSTEM.TASK, the TASK_TS field which is designated
as a ROW_TIMESTAMP always gets the HConstants.LATEST_TIMESTAMP value instead of the current
server-side wall clock time.

*The main side-effect of this bug is, subsequent creation and dropping of the same base table
will not upsert new DropChildViewTasks into the SYSTEM.TASK table.* 

Steps to reproduce:
1) Start HBase server with 4.15.0 Phoenix
2) Create a base table and a view on top of that base table:
{code:sql}
CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);

CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER, col5 INTEGER)
AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
{code}

3) Drop the base table with the cascade option:
{code:sql}
DROP TABLE Z_BASE_TABLE CASCADE;
{code}

4) Observe the SYSTEM.TASK table:
{code:sql}
SELECT TASK_TYPE, TASK_TS, TABLE_NAME, TASK_STATUS FROM SYSTEM.TASK;
{code}
--> gives the following:
{code:sql}
+------------+-------------------------------+---------------+--------------+
| TASK_TYPE  |            TASK_TS            |  TABLE_NAME   | TASK_STATUS  |
+------------+-------------------------------+---------------+--------------+
| 1          | 292278994-08-16 23:12:55.807  | Z_BASE_TABLE  | COMPLETED    |
+------------+-------------------------------+---------------+--------------+
{code}
That timestamp is basically HConstants.LATEST_TIMESTAMP.

5) Recreate the base table and view, then drop the base table, then observe SYSTEM.TASK again
(Steps 2 to 4) and now new DropChildViewTask is added for the base table created the second
time
{code:sql}
+------------+-------------------------------+---------------+--------------+
| TASK_TYPE  |            TASK_TS            |  TABLE_NAME   | TASK_STATUS  |
+------------+-------------------------------+---------------+--------------+
| 1          | 292278994-08-16 23:12:55.807  | Z_BASE_TABLE  | COMPLETED    |
+------------+-------------------------------+---------------+--------------+
{code}

Thus, the views are still there and this is most probably an issue with the ROW_TIMESTAMP
being assigned HConstants.LATEST_TIMESTAMP.
 

  was:
When we upsert DropChildViewTask entries into SYSTEM.TASK, the TASK_TS field which is designated
as a ROW_TIMESTAMP always gets the HConstants.LATEST_TIMESTAMP value instead of the current
server-side wall clock time.

*The main side-effect of this bug is, subsequent creation and dropping of the same base table
will not upsert new DropChildViewTasks into the SYSTEM.TASK table.* 

Steps to reproduce:
1) Start HBase server with 4.15.0 Phoenix
2) Create a base table and a view on top of that base table:
{code:sql}
CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);

CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER, col5 INTEGER)
AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
{code}

3) Drop the base table with the cascade option:
{code:sql}
DROP TABLE Z_BASE_TABLE CASCADE;
{code}

4) Observe the SYSTEM.TASK table:
{code:sql}
SELECT TASK_TYPE, TASK_TS, TABLE_NAME, TASK_STATUS FROM SYSTEM.TASK;
{code}
--> gives the following:
{code:sql}
+------------+-------------------------------+---------------+--------------+
| TASK_TYPE  |            TASK_TS            |  TABLE_NAME   | TASK_STATUS  |
+------------+-------------------------------+---------------+--------------+
| 1          | 292278994-08-16 23:12:55.807  | Z_BASE_TABLE  | COMPLETED    |
+------------+-------------------------------+---------------+--------------+
That timestamp is basically HConstants.LATEST_TIMESTAMP.
{code}

5) Recreate the base table and view, then drop the base table, then observe SYSTEM.TASK again
(Steps 2 to 4) and now new DropChildViewTask is added for the base table created the second
time
{code:sql}
+------------+-------------------------------+---------------+--------------+
| TASK_TYPE  |            TASK_TS            |  TABLE_NAME   | TASK_STATUS  |
+------------+-------------------------------+---------------+--------------+
| 1          | 292278994-08-16 23:12:55.807  | Z_BASE_TABLE  | COMPLETED    |
+------------+-------------------------------+---------------+--------------+
{code}

Thus, the views are still there and this is most probably an issue with the ROW_TIMESTAMP
being assigned HConstants.LATEST_TIMESTAMP.
 


> TASK_TS being set as HConstants.LATEST_TIMESTAMP in SYSTEM.TASK table
> ---------------------------------------------------------------------
>
>                 Key: PHOENIX-5546
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5546
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.15.0, 5.1.0
>            Reporter: Chinmay Kulkarni
>            Priority: Blocker
>             Fix For: 4.15.0, 5.1.0
>
>
> When we upsert DropChildViewTask entries into SYSTEM.TASK, the TASK_TS field which is
designated as a ROW_TIMESTAMP always gets the HConstants.LATEST_TIMESTAMP value instead of
the current server-side wall clock time.
> *The main side-effect of this bug is, subsequent creation and dropping of the same base
table will not upsert new DropChildViewTasks into the SYSTEM.TASK table.* 
> Steps to reproduce:
> 1) Start HBase server with 4.15.0 Phoenix
> 2) Create a base table and a view on top of that base table:
> {code:sql}
> CREATE TABLE IF NOT EXISTS Z_BASE_TABLE (ID INTEGER NOT NULL PRIMARY KEY, HOST VARCHAR(10),
FLAG BOOLEAN);
> CREATE VIEW Z_VIEW1 (col1 INTEGER, col2 INTEGER, col3 INTEGER, col4 INTEGER, col5 INTEGER)
AS SELECT * FROM Z_BASE_TABLE WHERE ID>10;
> {code}
> 3) Drop the base table with the cascade option:
> {code:sql}
> DROP TABLE Z_BASE_TABLE CASCADE;
> {code}
> 4) Observe the SYSTEM.TASK table:
> {code:sql}
> SELECT TASK_TYPE, TASK_TS, TABLE_NAME, TASK_STATUS FROM SYSTEM.TASK;
> {code}
> --> gives the following:
> {code:sql}
> +------------+-------------------------------+---------------+--------------+
> | TASK_TYPE  |            TASK_TS            |  TABLE_NAME   | TASK_STATUS  |
> +------------+-------------------------------+---------------+--------------+
> | 1          | 292278994-08-16 23:12:55.807  | Z_BASE_TABLE  | COMPLETED    |
> +------------+-------------------------------+---------------+--------------+
> {code}
> That timestamp is basically HConstants.LATEST_TIMESTAMP.
> 5) Recreate the base table and view, then drop the base table, then observe SYSTEM.TASK
again (Steps 2 to 4) and now new DropChildViewTask is added for the base table created the
second time
> {code:sql}
> +------------+-------------------------------+---------------+--------------+
> | TASK_TYPE  |            TASK_TS            |  TABLE_NAME   | TASK_STATUS  |
> +------------+-------------------------------+---------------+--------------+
> | 1          | 292278994-08-16 23:12:55.807  | Z_BASE_TABLE  | COMPLETED    |
> +------------+-------------------------------+---------------+--------------+
> {code}
> Thus, the views are still there and this is most probably an issue with the ROW_TIMESTAMP
being assigned HConstants.LATEST_TIMESTAMP.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message