You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Sergey Shelukhin (JIRA)" <ji...@apache.org> on 2018/04/03 21:48:00 UTC
[jira] [Updated] (HIVE-18570) ACID IOW implemented using base may
delete too much data
[ 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.
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.
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.
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.
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)