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)