hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (JIRA)" <>
Subject [jira] [Commented] (HIVE-21731) Hive import fails, post upgrade of source 3.0 cluster, to a target 4.0 cluster with strict managed table set to true.
Date Sat, 18 May 2019 15:55:00 GMT


Hive QA commented on HIVE-21731:

Here are the results of testing the latest attachment:

{color:green}SUCCESS:{color} +1 due to 2 test(s) being added or modified.

{color:red}ERROR:{color} -1 due to 1 failed/errored test(s), 16057 tests executed
*Failed tests:*
org.apache.hadoop.hive.llap.cache.TestBuddyAllocator.testMTT[2] (batchId=348)

Test results:
Console output:
Test logs:

Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
Tests exited with: TestsFailedException: 1 tests failed

This message is automatically generated.

ATTACHMENT ID: 12969076 - PreCommit-HIVE-Build

> Hive import fails, post upgrade of source 3.0 cluster, to a target 4.0 cluster with strict
managed table set to true.
> ---------------------------------------------------------------------------------------------------------------------
>                 Key: HIVE-21731
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>            Reporter: mahesh kumar behera
>            Assignee: mahesh kumar behera
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: HIVE-21731.01.patch, HIVE-21731.02.patch, HIVE-21731.03.patch, HIVE-21731.04.patch,
>          Time Spent: 3h 20m
>  Remaining Estimate: 0h
> The scenario is 
>  # Replication policy is set with hive  3.0 source cluster (strict managed table set
to false) and hive 4.0 target cluster with strict managed table set  true.
>  # User upgrades the 3.0 source cluster to 4.0 cluster using upgrade tool.
>  # The upgrade converts all managed tables to acid tables.
>  # In the next repl dump, user sets hive .repl .dump .include .acid .tables and hive
.repl .bootstrap. acid. tables set true triggering bootstrap of newly converted ACID tables.
>  # As the old tables are non-txn tables, dump is not filtering the events even tough
bootstrap acid table is set to true. This is causing the repl load to fail as the write id
is not set in the table object.
>  # If we ignore the event replay, the bootstrap is failing with dump directory mismatch
> The fix should be 
>  # Ignore dumping the alter table event if bootstrap acid table is set true and the alter
is converting a non-acid table to acid table.
>  # In case of bootstrap during incremental load, ignore the dump directory property set
in table object.

This message was sent by Atlassian JIRA

View raw message