[
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.
Txn 2 deletes rows committed by txn 1 that according to standard ACID semantics
it could have never observed and affected; this sequence of events is only
possible under read-uncommitted isolation level (so, 2 deletes rows written by
1 before 1 commits them).
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.
Txn 2 deletes rows committed by txn 1 that according to standard ACID semantics
it could have never observed and affected.
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).
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.
> 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
> Components: Transactions
> Reporter: Sergey Shelukhin
> Priority: Blocker
> Fix For: 3.0.0
>
>
> 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.
> Txn 2 deletes rows committed by txn 1 that according to standard ACID
> semantics it could have never observed and affected; this sequence of events
> is only possible under read-uncommitted isolation level (so, 2 deletes rows
> written by 1 before 1 commits them).
> 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)
