[jira] [Comment Edited] (HIVE-27021) Drop table should not be success on purge enabled tables if underlying HDFS data delete fails

["iBenny (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-27021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17685869#comment-17685869 ] 

iBenny edited comment on HIVE-27021 at 2/8/23 12:03 PM:
--------------------------------------------------------

[~zabetak] 

For requests create_table and add_partition, HMS call mkdir {color:#ff0000}before{color} changing the metadata, and the requests return {color:#ff0000}fails{color} when the exception occurs during mkdir. 

For requests drop_table and drop_partition, HMS call deletedir {color:#ff0000}after{color} changing the metadata, and the requests return {color:#ff0000}success{color} even if the exception occurs during deletedir.  

Do you think we can change the behavior of drop_table and drop_partition to the same as create_table and add_partition's in other to ensure operation consistency？


was (Author: ibenny):
[~zabetak] 

For requests create_table and add_partition, HMS call mkdir {color:#FF0000}before{color} changing the metadata, and the requests return {color:#FF0000}fails{color} when the exception occurs during mkdir. 

For requests drop_table and drop_partition, HMS call deletedir {color:#FF0000}after{color} changing the metadata, and the requests return {color:#FF0000}success{color} even if the exception occurs during deletedir.  

Do you think we can change the drop_table and drop_partition to the same as create_table and add_partition, to ensure the operation consistency？

> Drop table should not be success on purge enabled tables if underlying HDFS data delete fails
> ---------------------------------------------------------------------------------------------
>
>                 Key: HIVE-27021
>                 URL: https://issues.apache.org/jira/browse/HIVE-27021
>             Project: Hive
>          Issue Type: Bug
>            Reporter: iBenny
>            Priority: Minor
>              Labels: backward-incompatible
>
> User A has drop privs for a table, but does not have delete privs on table HDFS path & table purge is enabled. When User A fires drop table command, HMS metadata is removed but HDFS files are left as-is & drop is reported successful leaving stale files.
> For example, the drop table query is completed successfully. 
> {code:java}
> 0: jdbc:hive2://> drop table testtb_ex1
> INFO  : Semantic Analysis Completed (retrial = false)
> INFO  : Created Hive schema: Schema(fieldSchemas:null, properties:null)
> INFO  : Completed compiling command(queryId=hive_20221213121153_67cc8de3-9bd1-47c5-b2ec-13f6a0cd5125); Time taken: 0.032 seconds
> INFO  : Executing command(queryId=hive_20221213121153_67cc8de3-9bd1-47c5-b2ec-13f6a0cd5125): drop table testtb_ex1
> INFO  : Starting task [Stage-0:DDL] in serial mode
> INFO  : Completed executing command(queryId=hive_20221213121153_67cc8de3-9bd1-47c5-b2ec-13f6a0cd5125); Time taken: 0.413 seconds
> INFO  : OK
> No rows affected (0.516 seconds) {code}
> However, the table HDFS data deletion fails
> {code:java}
> 2022-12-13 12:11:53,700 ERROR org.apache.hadoop.hive.metastore.utils.MetaStoreUtils: [pool-6-thread-73]: Got exception: org.apache.hadoop.security.AccessControlException Permission denied by sticky bit: user
> =oozie, path="/warehouse/tablespace/external/hive/testtb_ex1":hive:hive:drwxr-xr-x, parent="/warehouse/tablespace/external/hive":hive:hive:drwxrwxrwt{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)