phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3534) Support multi region SYSTEM.CATALOG table
Date Thu, 12 Jul 2018 05:52:00 GMT


Hadoop QA commented on PHOENIX-3534:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment
  against master branch at commit aee568beb02cdf983bb10889902c338ea016e6c9.
  ATTACHMENT ID: 12931252

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 29 new or modified

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:red}-1 release audit{color}.  The applied patch generated 3 release audit warnings
(more than the master's current 0 warnings).

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than
    +            conn.createStatement().execute("CREATE LOCAL INDEX " + generateUniqueName()
+ " ON " + tableName + "(KV1)");
+            assertEquals(4, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k2"), fullView2IndexName));
+            assertEquals(5, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k3"), fullView2IndexName));
+            assertEquals(4, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k2"), fullView3IndexName));
+            assertEquals(5, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k3"), fullView3IndexName));
+            String view1DDL = "CREATE VIEW " + view1 + " ( VIEW_COL1 DECIMAL(10,2), VIEW_COL2
CHAR(256)) AS SELECT * FROM " + baseTable;
+            String divergedViewDDL = "CREATE VIEW " + divergedView + " ( VIEW_COL1 DECIMAL(10,2),
VIEW_COL2 CHAR(256)) AS SELECT * FROM " + baseTable;
+            String indexDDL = "CREATE INDEX " + divergedViewIndex + " ON " + divergedView
+ " (V1) include (V3)";
+            assertTableDefinition(tenant1Conn, view1, PTableType.VIEW, baseTable, 0, 7, 5,
 "PK1", "V1", "V2", "V3", "KV", "PK2", "VIEW_COL1", "VIEW_COL2");
+            assertTableDefinition(tenant2Conn, divergedView, PTableType.VIEW, baseTable,

     {color:red}-1 core tests{color}.  The patch failed these unit tests:

     {color:red}-1 core zombie tests{color}.  There are 4 zombie test(s): 	at org.apache.phoenix.end2end.DeleteIT.testPointDeleteRowFromTableWithImmutableIndex(
	at org.apache.phoenix.end2end.DeleteIT.testPointDeleteRowFromTableWithImmutableIndex(
	at org.apache.phoenix.end2end.DefaultColumnValueIT.testDefaultColumnValue(

Test results:
Release audit warnings:
Console output:

This message is automatically generated.

> Support multi region SYSTEM.CATALOG table
> -----------------------------------------
>                 Key: PHOENIX-3534
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>            Priority: Major
>             Fix For: 5.0.0, 4.15.0
>         Attachments: PHOENIX-3534-v2.patch, PHOENIX-3534-v3.patch, PHOENIX-3534.patch
> Currently Phoenix requires that the SYSTEM.CATALOG table is single region based on the
server-side row locks being held for operations that impact a table and all of it's views.
For example, adding/removing a column from a base table pushes this change to all views.
> As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), when a new
table is created we can do a lazy cleanup  of any rows that may be left over from a failed
DDL call (kudos to [~lhofhansl] for coming up with this idea). To implement this efficiently,
we'd need to also do PHOENIX-2051 so that we can efficiently find derived views.
> The implementation would rely on an optimistic concurrency model based on checking our
sequence numbers for each table/view before/after updating. Each table/view row would be individually
locked for their change (metadata for a view or table cannot span regions due to our split
policy), with the sequence number being incremented under lock and then returned to the client.

This message was sent by Atlassian JIRA

View raw message