You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Kishen Das (Jira)" <ji...@apache.org> on 2021/03/18 16:50:00 UTC
[jira] [Commented] (HIVE-24794) [HMS] Populate tableId in the
response of get_valid_write_ids API
[ https://issues.apache.org/jira/browse/HIVE-24794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304279#comment-17304279 ]
Kishen Das commented on HIVE-24794:
-----------------------------------
This would take care of the above issue -> https://issues.apache.org/jira/browse/HIVE-24662 .
> [HMS] Populate tableId in the response of get_valid_write_ids API
> -----------------------------------------------------------------
>
> Key: HIVE-24794
> URL: https://issues.apache.org/jira/browse/HIVE-24794
> Project: Hive
> Issue Type: Sub-task
> Components: HiveServer2
> Reporter: Kishen Das
> Assignee: Kishen Das
> Priority: Major
>
> In HS2, after query compilation phase, we acquire lock in DriverTxnHandler.
> isValidTxnListState and later ensure there are no conflicting transactions by using driverContext.getTxnManager().getLatestTxnIdInConflict(); . This doesn't work well, if there are external entities that drop and recreate the table with the same name. So, we should also make sure the tableId itself is not changed, after lock has been acquired. This Jira is to enhance getValidWriteIdList to return tableId as well. Idea is to cache the tableId in SessionState and later compare it with what getValidWriteIdList returns. If the table was dropped and recreated, the tableId will not match and we have to recompile the query. Caching the tableId in SessionState will be done as part of a separate Jira.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)