[HIVE-15044] LockManager may be too coarse grained

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.0.0
• Component/s: Transactions
• Assignee: Unassigned
• Reporter: Eugene Koifman
• Created: 24/Oct/16 20:06
• Updated: 28/Jul/21 14:13

Description

Consider

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')")
insert into target partition(p=1,q) values (1,2,3)

this insert will lock the whole table. See

DbTxnManager.acquireLocks()
switch (output.getType()) {
        case DUMMYPARTITION:   //

Insert operation runs with SHARED_READ lock but once HIVE-15032 is addressed this will be an issue for Update/Delete/Merge which use a more restrictive SHARED_WRITE lock.

This can probably be achieved using "like /db/table/part/*" predicate making the LM operations more expensive TxnHandler.checkLock()

Issue Links

• relates to: HIVE-15032 Update/Delete statements use dynamic partitions when it's not necessary