[ 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 no 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 seems to be 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 | +------------+-------------------------------+---------------+--------------+ {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 seems to be 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 > Assignee: 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 no 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 seems to be an issue with the > ROW_TIMESTAMP being assigned HConstants.LATEST_TIMESTAMP. -- This message was sent by Atlassian Jira (v8.3.4#803005)