[ 
https://issues.apache.org/jira/browse/HIVE-21731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mahesh kumar behera updated HIVE-21731:
---------------------------------------
    Attachment: HIVE-21731.02.patch

> 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: https://issues.apache.org/jira/browse/HIVE-21731
>             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
>
>          Time Spent: 10m
>  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 error.
> 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
(v7.6.3#76005)

Reply via email to