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 2015/09/16 20:38:45 UTC
[jira] [Updated] (HIVE-11848) tables in subqueries don't get locked
[ https://issues.apache.org/jira/browse/HIVE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eugene Koifman updated HIVE-11848:
----------------------------------
Description:
Consider
{noformat}
update acidTbl set b=19 where acidTbl.b in(select I.b from nonAcidOrcTbl I where I.a = 3)
{noformat}
noAcidOrcTbl doesn't get locked at all. (SHARED_WRITE is taken on acidTbl).
Same for __delete__ with subquery
This is is because the ReadEntity for nonAcidOrcTbl is skipped by
{noformat}
for (ReadEntity input : plan.getInputs()) {
if (!input.needsLock() || input.isUpdateOrDelete()) {
// We don't want to acquire readlocks during update or delete as we'll be acquiring write
// locks instead.
continue;
}
{noformat}
whatever sets isUpdateOrDelete() flag doesn't pay attention to whether the table is written to or not.
HIVE-10150 was a similar issue, abstractly
was:
Consider
{noformat}
update acidTbl set b=19 where acidTbl.b in(select I.b from nonAcidOrcTbl I where I.a = 3)
{noformat}
noAcidOrcTbl doesn't get locked at all. (SHARED_WRITE is taken on acidTbl).
This is is because the ReadEntity for nonAcidOrcTbl is skipped by
{noformat}
for (ReadEntity input : plan.getInputs()) {
if (!input.needsLock() || input.isUpdateOrDelete()) {
// We don't want to acquire readlocks during update or delete as we'll be acquiring write
// locks instead.
continue;
}
{noformat}
whatever sets isUpdateOrDelete() flag doesn't pay attention to whether the table is written to or not.
HIVE-10150 was a similar issue, abstractly
> tables in subqueries don't get locked
> -------------------------------------
>
> Key: HIVE-11848
> URL: https://issues.apache.org/jira/browse/HIVE-11848
> Project: Hive
> Issue Type: Bug
> Components: Locking, Transactions
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
>
> Consider
> {noformat}
> update acidTbl set b=19 where acidTbl.b in(select I.b from nonAcidOrcTbl I where I.a = 3)
> {noformat}
> noAcidOrcTbl doesn't get locked at all. (SHARED_WRITE is taken on acidTbl).
> Same for __delete__ with subquery
> This is is because the ReadEntity for nonAcidOrcTbl is skipped by
> {noformat}
> for (ReadEntity input : plan.getInputs()) {
> if (!input.needsLock() || input.isUpdateOrDelete()) {
> // We don't want to acquire readlocks during update or delete as we'll be acquiring write
> // locks instead.
> continue;
> }
> {noformat}
> whatever sets isUpdateOrDelete() flag doesn't pay attention to whether the table is written to or not.
> HIVE-10150 was a similar issue, abstractly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)