[
https://issues.apache.org/jira/browse/HIVE-24445?focusedWorklogId=557913&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-557913
]
ASF GitHub Bot logged work on HIVE-24445:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 25/Feb/21 13:48
Start Date: 25/Feb/21 13:48
Worklog Time Spent: 10m
Work Description: pvargacl commented on a change in pull request #2020:
URL: https://github.com/apache/hive/pull/2020#discussion_r582835527
##########
File path: ql/src/java/org/apache/hadoop/hive/ql/metadata/Hive.java
##########
@@ -1129,14 +1129,17 @@ public void createTable(Table tbl, boolean ifNotExists,
principalPrivs.setRolePrivileges(grants.getRoleGrants());
tTbl.setPrivileges(principalPrivs);
}
+ if (HiveConf.getBoolVar(conf,
ConfVars.HIVE_TXN_LOCKLESS_READS_ENABLED) &&
AcidUtils.isTransactionalTable(tbl)) {
Review comment:
i would consider do this for every transactional table, regardless of
the config. So we would have consistent naming convention everywhere + I think
it would help reduce the cases to consider (like what happens if the config is
on for some time, then it is turn off, or if somebody turns this off in session
level etc.)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 557913)
Time Spent: 2h 40m (was: 2.5h)
> Non blocking DROP table implementation
> --------------------------------------
>
> Key: HIVE-24445
> URL: https://issues.apache.org/jira/browse/HIVE-24445
> Project: Hive
> Issue Type: New Feature
> Components: Hive
> Reporter: Zoltan Chovan
> Assignee: Zoltan Chovan
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Implement a way to execute drop table operations in a way that doesn't have
> to wait for currently running read operations to be finished.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
