[
https://issues.apache.org/jira/browse/HIVE-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-18570:
------------------------------------
Description:
Suppose we have a table with delta_0 insert data.
Txn 1 starts an insert into delta_1.
Txn 2 starts an IOW into base_2.
Txn 2 commits.
Txn 1 commits after txn 2 but its results would be invisible.
If we treat IOW foo like DELETE FROM foo (to reason about it w.r.t. ACID
semantics), it seems to me this sequence of events is only possible under
read-uncommitted isolation level (so, 2 deletes rows written by 1).
Under any other isolation level rows written by 1 must survive, or there must
be some lock based change in sequence or conflict.
Update: to clarify, if 1 ran an update on rows instead of an insert, and 2
still ran an IOW/delete, row lock conflict (or equivalent) should cause one of
them to fail.
was:
Suppose we have a table with delta_0 insert data.
Txn 1 starts an insert into delta_1.
Txn 2 starts an IOW into base_2.
Txn 2 commits.
Txn 1 commits after txn 2 but its results would be invisible.
If we treat IOW foo like DELETE FROM foo (to reason about it w.r.t. ACID
semantics), it seems to me this sequence of events is only possible under
read-uncommitted isolation level (so, 2 deletes rows written by 1).
Under any other isolation level rows written by 1 must survive, or there must
be some lock based change in sequence or conflict.
Update: to clarify, if 1 ran an update on rows and 2 ran a delete, row lock
conflict would cause one of them to fail.
> ACID IOW implemented using base may delete too much data
> --------------------------------------------------------
>
> Key: HIVE-18570
> URL: https://issues.apache.org/jira/browse/HIVE-18570
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Priority: Major
>
> Suppose we have a table with delta_0 insert data.
> Txn 1 starts an insert into delta_1.
> Txn 2 starts an IOW into base_2.
> Txn 2 commits.
> Txn 1 commits after txn 2 but its results would be invisible.
> If we treat IOW foo like DELETE FROM foo (to reason about it w.r.t. ACID
> semantics), it seems to me this sequence of events is only possible under
> read-uncommitted isolation level (so, 2 deletes rows written by 1).
> Under any other isolation level rows written by 1 must survive, or there must
> be some lock based change in sequence or conflict.
> Update: to clarify, if 1 ran an update on rows instead of an insert, and 2
> still ran an IOW/delete, row lock conflict (or equivalent) should cause one
> of them to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
