You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Eugene Koifman (JIRA)" <ji...@apache.org> on 2017/10/04 18:25:00 UTC
[jira] [Commented] (HIVE-17650) DDLTask.handleRemoveMm() assumes
locks not present
[ https://issues.apache.org/jira/browse/HIVE-17650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191780#comment-16191780 ]
Eugene Koifman commented on HIVE-17650:
---------------------------------------
perhaps this handled by DDLSemanctiAnalyzer.addInputsOutputsAlterTable(boolean doForceExclusive)
> DDLTask.handleRemoveMm() assumes locks not present
> --------------------------------------------------
>
> Key: HIVE-17650
> URL: https://issues.apache.org/jira/browse/HIVE-17650
> Project: Hive
> Issue Type: Sub-task
> Components: Transactions
> Reporter: Eugene Koifman
>
> This moves every file in the table from under delta_x_x/ to root of the table/partition
> How would this work for bucketed tables? Will it create bucket_x_copy_N files?
> This could create 1000s of copy_N files - this will likely break something
> The comments in the method assume locks are present - this would imply that there are appropriate Read/WriteEntity objects already created - I doubt this is the case for a table property change.
> It seems like this kind of op should require an Exclusive lock at table level to prevent concurrent inserts (into new delta_x_x/)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)