[
https://issues.apache.org/jira/browse/HIVE-24933?focusedWorklogId=803069&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-803069
]
ASF GitHub Bot logged work on HIVE-24933:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 24/Aug/22 01:15
Start Date: 24/Aug/22 01:15
Worklog Time Spent: 10m
Work Description: jhungund opened a new pull request, #3544:
URL: https://github.com/apache/hive/pull/3544
Replication fails for transactional tables having same name as dropped
external tables.
Summary of the change:
While setting up the tasks during the repl-load phase of the replication,
delay the access to
table metadata until the task execution. This will avoid inconsistent
metadata access during
task creation.
Root Cause Analysis:
Background:
During the incremental load phase of replication, all event logs are
processed sequentially.
Multiple tasks are spawned/created during the processing of each event.
All the spawned tasks are subsequently, executed sequantially.
Scenario of the issue:
The issue is seen in the following scenario:
1. An external table(Eg. T1) created, is replicated, to target cluster
during earlier replication cycles.
2. This external table is dropped.
3. An new managed table with the same name (T1) is recreated.
4. The subsequent repl-load phase fails.
Root cause:
1. The above mentioned operations (table drop and recreation) are propogated
to the target cluster
via event logs during the subsequent incremental phase of replication.
2. We create DDL tasks to drop the external table for drop-table event.
3. We also create new tasks to create new managed tables.
4. Some additional events are logged which create tasks to load the newly
created table.
5. During the creation of these load-table tasks, we try to access metadata
corresponding to the new table.
During normal scenario of a fresh table creation, the metadata store will
not have data correspoding to the new table (yet to be created).
However, in this scenario, the old table still exists and hence, we end
up using the metadata corrsesponding to old table(external).
We try to use this metadata to create the load tasks for the new table.
During the exeuciton of these load tasks, which execute after the drop
and recreate tasks, we find that the metadata set in the
task context is stale and is inconsistent with the newly created table.
Hence, the error.
Fix:
Do not access the table metadata during the task creation phase for
table-load.
Instead, access the metadata during the task execution. By that time,
the metadata is updated to the latest state with the previously executed
tasks.
Change-Id: I79ed804617dcdadb51f961a933f4023ac0b6f509
<!--
Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, please read our contributor guidelines:
https://cwiki.apache.org/confluence/display/Hive/HowToContribute
2. Ensure that you have created an issue on the Hive project JIRA:
https://issues.apache.org/jira/projects/HIVE/summary
3. Ensure you have added or run the appropriate tests for your PR:
4. If the PR is unfinished, add '[WIP]' in your PR title, e.g.,
'[WIP]HIVE-XXXXX: Your PR title ...'.
5. Be sure to keep the PR description updated to reflect all changes.
6. Please write your PR title to summarize what this PR proposes.
7. If possible, provide a concise example to reproduce the issue for a
faster review.
-->
### What changes were proposed in this pull request?
<!--
Please clarify what changes you are proposing. The purpose of this section
is to outline the changes and how this PR fixes the issue.
If possible, please consider writing useful notes for better and faster
reviews in your PR. See the examples below.
1. If you refactor some codes with changing classes, showing the class
hierarchy will help reviewers.
2. If you fix some SQL features, you can provide some references of other
DBMSes.
3. If there is design documentation, please add the link.
4. If there is a discussion in the mailing list, please add the link.
-->
### Why are the changes needed?
<!--
Please clarify why the changes are needed. For instance,
1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, you can clarify why it is a bug.
-->
### Does this PR introduce _any_ user-facing change?
<!--
Note that it means *any* user-facing change including all aspects such as
the documentation fix.
If yes, please clarify the previous behavior and the change this PR proposes
- provide the console output, description, screenshot and/or a reproducable
example to show the behavior difference if possible.
If possible, please also clarify if this is a user-facing change compared to
the released Hive versions or within the unreleased branches such as master.
If no, write 'No'.
-->
### How was this patch tested?
- Unit-Tested
Issue Time Tracking
-------------------
Worklog Id: (was: 803069)
Time Spent: 4.5h (was: 4h 20m)
> Replication fails for transactional tables having same name as dropped
> non-transactional table
> ----------------------------------------------------------------------------------------------
>
> Key: HIVE-24933
> URL: https://issues.apache.org/jira/browse/HIVE-24933
> Project: Hive
> Issue Type: Bug
> Reporter: Pratyush Madhukar
> Assignee: Pratyush Madhukar
> Priority: Major
> Labels: pull-request-available
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
