You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Chinmay Kulkarni (Jira)" <ji...@apache.org> on 2019/10/25 07:32:00 UTC
[jira] [Created] (PHOENIX-5546) TASK_TS being set as
HConstants.LATEST_TIMESTAMP in SYSTEM.TASK table
Chinmay Kulkarni created PHOENIX-5546:
-----------------------------------------
Summary: 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
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}
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)