[jira] [Updated] (PHOENIX-5065) Inconsistent treatment of NULL and empty string
[
https://issues.apache.org/jira/browse/PHOENIX-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Jacoby updated PHOENIX-5065:
-
Description:
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows. Note that FOO does not exist, and is just a nonsense string
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
--Returns 0 rows, but slowly
{code}
was:
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows.
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
--Returns 0 rows, but slowly
{code}
> Inconsistent treatment of NULL and empty string
> ---
>
> Key: PHOENIX-5065
> URL: https://issues.apache.org/jira/browse/PHOENIX-5065
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Geoffrey Jacoby
>Priority: Major
>
> Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
> doesn't handle them consistently internally either.
> In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
> for empty string and NULL to be equivalent. That's inconsistent with other
> SQL dialects (in which NULL is never equal to anything, including itself),
> but if that's our documented behavior, then that's fine unless PHOENIX-2422
> to change it is ever worked.
> But consider the following queries:
> {code:java}
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
> -- Returns some number of rows. Call it N
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
> -- Returns N rows. Note that FOO does not exist, and is just a nonsense string
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
> --Returns 0 rows, but slowly
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5065) Inconsistent treatment of NULL and empty string
[
https://issues.apache.org/jira/browse/PHOENIX-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Jacoby updated PHOENIX-5065:
-
Description:
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows.
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANTID = '' OR TENANT_ID = 'FOO'
--Returns 0 rows, but slowly
{code}
was:
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows.
{code}
> Inconsistent treatment of NULL and empty string
> ---
>
> Key: PHOENIX-5065
> URL: https://issues.apache.org/jira/browse/PHOENIX-5065
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Geoffrey Jacoby
>Priority: Major
>
> Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
> doesn't handle them consistently internally either.
> In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
> for empty string and NULL to be equivalent. That's inconsistent with other
> SQL dialects (in which NULL is never equal to anything, including itself),
> but if that's our documented behavior, then that's fine unless PHOENIX-2422
> to change it is ever worked.
> But consider the following queries:
> {code:java}
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
> -- Returns some number of rows. Call it N
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
> -- Returns N rows.
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANTID = '' OR TENANT_ID = 'FOO'
> --Returns 0 rows, but slowly
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4832) Add Canary Test Tool for Phoenix Query Server
[ https://issues.apache.org/jira/browse/PHOENIX-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Poon updated PHOENIX-4832: -- Affects Version/s: 5.0.0 4.14.1 > Add Canary Test Tool for Phoenix Query Server > - > > Key: PHOENIX-4832 > URL: https://issues.apache.org/jira/browse/PHOENIX-4832 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.14.1 >Reporter: Ashutosh Parekh >Assignee: Swaroopa Kadam >Priority: Minor > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4832-4.x-HBase-1.4.patch, > PHOENIX-4832-4.x-HBase-1.4.patch, PHOENIX-4832-master.patch, > PHOENIX-4832.patch > > > A suggested improvement is to add a Canary Test tool to the Phoenix Query > Server. It will execute a set of Basic Tests (CRUD) against a PQS end-point > and report on the proper functioning and testing results. A configurable Log > Sink can help to publish the results as required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-5065) Inconsistent treatment of NULL and empty string
[
https://issues.apache.org/jira/browse/PHOENIX-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Jacoby updated PHOENIX-5065:
-
Description:
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows.
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
--Returns 0 rows, but slowly
{code}
was:
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows.
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANTID = '' OR TENANT_ID = 'FOO'
--Returns 0 rows, but slowly
{code}
> Inconsistent treatment of NULL and empty string
> ---
>
> Key: PHOENIX-5065
> URL: https://issues.apache.org/jira/browse/PHOENIX-5065
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Geoffrey Jacoby
>Priority: Major
>
> Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
> doesn't handle them consistently internally either.
> In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
> for empty string and NULL to be equivalent. That's inconsistent with other
> SQL dialects (in which NULL is never equal to anything, including itself),
> but if that's our documented behavior, then that's fine unless PHOENIX-2422
> to change it is ever worked.
> But consider the following queries:
> {code:java}
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
> -- Returns some number of rows. Call it N
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
> -- Returns 0 rows
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
> -- Returns N rows.
> SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '' OR TENANT_ID = 'FOO'
> --Returns 0 rows, but slowly
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-5065) Inconsistent treatment of NULL and empty string
Geoffrey Jacoby created PHOENIX-5065:
Summary: Inconsistent treatment of NULL and empty string
Key: PHOENIX-5065
URL: https://issues.apache.org/jira/browse/PHOENIX-5065
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.14.1
Reporter: Geoffrey Jacoby
Phoenix doesn't handle NULLs consistently with other SQL dialects, and it
doesn't handle them consistently internally either.
In PHOENIX-2422, [~jamestaylor] mentioned that Phoenix's intended behavior is
for empty string and NULL to be equivalent. That's inconsistent with other SQL
dialects (in which NULL is never equal to anything, including itself), but if
that's our documented behavior, then that's fine unless PHOENIX-2422 to change
it is ever worked.
But consider the following queries:
{code:java}
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID = '';
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IS NULL;
-- Returns some number of rows. Call it N
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('');
-- Returns 0 rows
SELECT COUNT(*) FROM SYSTEM.CATALOG WHERE TENANT_ID IN ('', 'FOO');
-- Returns N rows.
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (PHOENIX-5018) Index mutations created by IndexTool will have wrong timestamps
[ https://issues.apache.org/jira/browse/PHOENIX-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby reassigned PHOENIX-5018: Assignee: Kadir OZDEMIR (was: Geoffrey Jacoby) > Index mutations created by IndexTool will have wrong timestamps > --- > > Key: PHOENIX-5018 > URL: https://issues.apache.org/jira/browse/PHOENIX-5018 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.14.0, 5.0.0 >Reporter: Geoffrey Jacoby >Assignee: Kadir OZDEMIR >Priority: Major > > When doing a full rebuild (or initial async build) on an index using the > IndexTool and PhoenixIndexImportDirectMapper, we generate the index mutations > by creating an UPSERT SELECT query from the base table to the index, then > taking the Mutations from it and inserting it directly into the index via an > HBase HTable. > The timestamps of the Mutations use the default HBase behavior, which is to > take the current wall clock. However, the timestamp of an index KeyValue > should use the timestamp of the initial KeyValue in the base table. > Having base table and index timestamps out of sync can cause all sorts of > weird side effects, such as if the base table has data with an expired TTL > that isn't expired in the index yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-5027) PhoenixIndexImportDirectMapper retried mappers can succeed without inserting all index data
[ https://issues.apache.org/jira/browse/PHOENIX-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey Jacoby reassigned PHOENIX-5027: Assignee: Geoffrey Jacoby > PhoenixIndexImportDirectMapper retried mappers can succeed without inserting > all index data > --- > > Key: PHOENIX-5027 > URL: https://issues.apache.org/jira/browse/PHOENIX-5027 > Project: Phoenix > Issue Type: Bug >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > > On two recent occasions I've rebuilt a large global immutable index by doing > a DROP/CREATE and ended up with missing index data, though it doesn't happen > every time. Here's what happened: > 1. PhoenixMRJobSubmitter correctly detects the index rebuild is necessary, > and invokes IndexTool. > 2. IndexTool enqueues a MapReduce job using PhoenixIndexImportDirectMapper > 3. Some mappers fail because of timeouts due to heavy splitting on the new > index table > 4. Those mappers are retried and succeed. The MR job as a whole completes > successfully. > 5. RowCounter and IndexScrutinyTool show millions of rows are missing from > the index, with keys that imply they were part of the failed mappers > Aside from the timestamp glitch I pointed out in PHOEIX-5018, the code in > PhoenixIndexImportDirectMapper _looks_ idempotent on a rerun, so I've been > struggling to find the cause of the missing index data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org
[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] Hello Apache projects, I am writing to you because you may have git repositories on the git-wip-us server, which is slated to be decommissioned in the coming months. All repositories will be moved to the new gitbox service which includes direct write access on github as well as the standard ASF commit access via gitbox.apache.org. ## Why this move? ## The move comes as a result of retiring the git-wip service, as the hardware it runs on is longing for retirement. In lieu of this, we have decided to consolidate the two services (git-wip and gitbox), to ease the management of our repository systems and future-proof the underlying hardware. The move is fully automated, and ideally, nothing will change in your workflow other than added features and access to GitHub. ## Timeframe for relocation ## Initially, we are asking that projects voluntarily request to move their repositories to gitbox, hence this email. The voluntary timeframe is between now and January 9th 2019, during which projects are free to either move over to gitbox or stay put on git-wip. After this phase, we will be requiring the remaining projects to move within one month, after which we will move the remaining projects over. To have your project moved in this initial phase, you will need: - Consensus in the project (documented via the mailing list) - File a JIRA ticket with INFRA to voluntarily move your project repos over to gitbox (as stated, this is highly automated and will take between a minute and an hour, depending on the size and number of your repositories) To sum up the preliminary timeline; - December 9th 2018 -> January 9th 2019: Voluntary (coordinated) relocation - January 9th -> February 6th: Mandated (coordinated) relocation - February 7th: All remaining repositories are mass migrated. This timeline may change to accommodate various scenarios. ## Using GitHub with ASF repositories ## When your project has moved, you are free to use either the ASF repository system (gitbox.apache.org) OR GitHub for your development and code pushes. To be able to use GitHub, please follow the primer at: https://reference.apache.org/committer/github We appreciate your understanding of this issue, and hope that your project can coordinate voluntarily moving your repositories in a timely manner. All settings, such as commit mail targets, issue linking, PR notification schemes etc will automatically be migrated to gitbox as well. With regards, Daniel on behalf of ASF Infra. PS:For inquiries, please reply to us...@infra.apache.org, not your project's dev list :-).
[jira] [Updated] (PHOENIX-5055) Split mutations batches probably affects correctness of index data
[
https://issues.apache.org/jira/browse/PHOENIX-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai updated PHOENIX-5055:
Attachment: PHOENIX-5055-4.x-HBase-1.4-v3.patch
> Split mutations batches probably affects correctness of index data
> --
>
> Key: PHOENIX-5055
> URL: https://issues.apache.org/jira/browse/PHOENIX-5055
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Jaanai
>Assignee: Jaanai
>Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ConcurrentTest.java,
> PHOENIX-5055-4.x-HBase-1.4-v2.patch, PHOENIX-5055-4.x-HBase-1.4-v3.patch,
> PHOENIX-5055-v4.x-HBase-1.4.patch
>
>
> In order to get more performance, we split the list of mutations into
> multiple batches in MutationSate. For one upsert SQL with some null values
> that will produce two type KeyValues(Put and DeleteColumn), These KeyValues
> should have the same timestamp so that keep on an atomic operation for
> corresponding the row key.
> [^ConcurrentTest.java] produced some random upsert/delete SQL and
> concurrently executed, some SQL snippets as follows:
> {code:java}
> 1149:UPSERT INTO ConcurrentReadWritTest(A,C,E,F,G) VALUES
> ('3826','2563','3052','3170','3767');
> 1864:UPSERT INTO ConcurrentReadWritTest(A,B,C,D,E,F,G) VALUES
> ('2563','4926','3526','678',null,null,'1617');
> 2332:UPSERT INTO ConcurrentReadWritTest(A,B,C,D,E,F,G) VALUES
> ('1052','2563','1120','2314','1456',null,null);
> 2846:UPSERT INTO ConcurrentReadWritTest(A,B,C,D,G) VALUES
> ('1922','146',null,'469','2563');
> 2847:DELETE FROM ConcurrentReadWritTest WHERE A = '2563’;
> {code}
> Found incorrect indexed data for the index tables by sqlline.
> !https://gw.alicdn.com/tfscom/TB1nSDqpxTpK1RjSZFGXXcHqFXa.png|width=665,height=400!
> Debugged the mutations of batches on the server side. the DeleteColumns and
> Puts were splitted into the different batches for the once upsert, the
> DeleteFaimly also was executed by another thread. due to DeleteColumns's
> timestamp is larger than DeleteFaimly under multiple threads.
> !https://gw.alicdn.com/tfscom/TB1frHmpCrqK1RjSZK9XXXyypXa.png|width=901,height=120!
>
> Running the following:
> {code:java}
> conn.createStatement().executeUpdate( "CREATE TABLE " + tableName + " (" + "A
> VARCHAR NOT NULL PRIMARY KEY," + "B VARCHAR," + "C VARCHAR," + "D VARCHAR)
> COLUMN_ENCODED_BYTES = 0");
> conn.createStatement().executeUpdate("CREATE INDEX " + indexName + " on " +
> tableName + " (C) INCLUDE(D)");
> conn.createStatement().executeUpdate("UPSERT INTO " + tableName + "(A,B,C,D)
> VALUES ('A2','B2','C2','D2')");
> conn.createStatement().executeUpdate("UPSERT INTO " + tableName + "(A,B,C,D)
> VALUES ('A3','B3', 'C3', null)");
> {code}
> dump IndexMemStore:
> {code:java}
> hbase.index.covered.data.IndexMemStore(117):
> Inserting:\x01A3/0:D/1542190446218/DeleteColumn/vlen=0/seqid=0/value=
> phoenix.hbase.index.covered.data.IndexMemStore(133): Current kv state:
> phoenix.hbase.index.covered.data.IndexMemStore(135): KV:
> \x01A3/0:B/1542190446167/Put/vlen=2/seqid=5/value=B3
> phoenix.hbase.index.covered.data.IndexMemStore(135): KV:
> \x01A3/0:C/1542190446167/Put/vlen=2/seqid=5/value=C3
> phoenix.hbase.index.covered.data.IndexMemStore(135): KV:
> \x01A3/0:D/1542190446218/DeleteColumn/vlen=0/seqid=0/value=
> phoenix.hbase.index.covered.data.IndexMemStore(135): KV:
> \x01A3/0:_0/1542190446167/Put/vlen=1/seqid=5/value=x
> phoenix.hbase.index.covered.data.IndexMemStore(137): == END MemStore
> Dump ==
> {code}
>
> The DeleteColumn's timestamp larger than other mutations.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
