[ 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)