[
https://issues.apache.org/jira/browse/HIVE-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736090#comment-15736090
]
Alan Gates commented on HIVE-15048:
-----------------------------------
I'm not sure I understand the change here. The previous code looks like it was
trying to avoid locking the whole table by figuring out which partitions would
be read and only locking those partitions. It looks like this goes wrong when
there's a subquery involved, but in general should be sound. If I understand
your changes you're just moving it to always use dynamic partitioning. But
that locks the whole table, which we don't want.
> Update/Delete statement using wrong WriteEntity when subqueries are involved
> ----------------------------------------------------------------------------
>
> Key: HIVE-15048
> URL: https://issues.apache.org/jira/browse/HIVE-15048
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 1.0.0
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
> Priority: Critical
> Attachments: HIVE-15048.01.patch, HIVE-15048.02.patch,
> HIVE-15048.03.patch, HIVE-15048.04.patch
>
>
> See TestDbTxnManager2 for referenced methods
> {noformat}
> checkCmdOnDriver(driver.run("create table target (a int, b int) " +
> "partitioned by (p int, q int) clustered by (a) into 2 buckets " +
> "stored as orc TBLPROPERTIES ('transactional'='true')"));
> checkCmdOnDriver(driver.run("create table source (a1 int, b1 int, p1 int,
> q1 int) clustered by (a1) into 2 buckets stored as orc TBLPROPERTIES
> ('transactional'='true')"));
> checkCmdOnDriver(driver.run("insert into target partition(p,q) values
> (1,2,1,2), (3,4,1,2), (5,6,1,3), (7,8,2,2)"));
> checkCmdOnDriver(driver.run(
> "update source set b1 = 1 where p1 in (select t.q from target t where
> t.p=2)"));
> {noformat}
> The last Update stmt creates the following Entity objects in the QueryPlan
> inputs: [default@source, default@target, default@target@p=2/q=2]
> outputs: [default@target@p=2/q=2]
> Which is clearly wrong for outputs - the target table is not even
> partitioned(or called 'target').
> This happens in UpdateDeleteSemanticAnalyzer.reparseAndSuperAnalyze()
> I suspect
> update T ... where T.p IN (select d from T where ...)
> type query would also get messed up (but not necessarily fail) if T is
> partitioned and the subquery filters out some partitions but that does not
> mean that the same partitions are filtered out in the parent query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
