Bug #61546 | Bogus calls to btr_cur_optimistic_insert() and btr_cur_optimistic_update() | ||
---|---|---|---|
Submitted: | 16 Jun 2011 21:20 | Modified: | 14 May 2013 12:07 |
Reporter: | Nizameddin Ordulu | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB Plugin storage engine | Severity: | S4 (Feature request) |
Version: | 5.1.52, 5.1.59, 5.6.99 | OS: | Linux |
Assigned to: | CPU Architecture: | Any | |
Tags: | compression, Contribution |
[16 Jun 2011 21:20]
Nizameddin Ordulu
[16 Jun 2011 21:21]
Nizameddin Ordulu
The fix here only fixes the redundant calls to btr_cur_optimistic_insert(). btr_cur_pessimistic_update() needs the return code from btr_cur_optimistic_update() so it's a bit more complicated to fix this case.
[23 Jul 2011 11:37]
Sveta Smirnova
Thank you for the report. Verified as described. Regular InnoDB affected as well. Here is excerpt for btr_cur_optimistic_update: $vim storage/innobase/row/row0upd.c ... } else { 1551 err = btr_cur_optimistic_update(BTR_NO_LOCKING_FLAG, 1552 btr_cur, node->update, 1553 node->cmpl_info, thr, mtr); 1554 } 1555 1556 mtr_commit(mtr); 1557 1558 if (err == DB_SUCCESS) { 1559 1560 return(err); 1561 } 1562 1563 if (buf_LRU_buf_pool_running_out()) { 1564 1565 return(DB_LOCK_TABLE_FULL); 1566 } 1567 /* We may have to modify the tree structure: do a pessimistic descent 1568 down the index tree */ 1569 1570 mtr_start(mtr); 1571 1572 /* NOTE: this transaction has an s-lock or x-lock on the record and 1573 therefore other transactions cannot modify the record when we have no 1574 latch on the page. In addition, we assume that other query threads of 1575 the same transaction do not modify the record in the meantime. 1576 Therefore we can assert that the restoration of the cursor succeeds. */ 1577 1578 ut_a(btr_pcur_restore_position(BTR_MODIFY_TREE, pcur, mtr)); 1579 1580 ut_ad(!rec_get_deleted_flag(btr_pcur_get_rec(pcur), 1581 dict_table_is_comp(index->table))); 1582 1583 err = btr_cur_pessimistic_update( 1584 BTR_NO_LOCKING_FLAG | BTR_KEEP_POS_FLAG, btr_cur, 1585 &big_rec, node->update, node->cmpl_info, thr, mtr);
[2 Aug 2011 20:12]
Nizameddin Ordulu
Sveta: Does your excerpt include a fix? It doesn't seem to be different from the original source code. Are you planning to fix the bug for redundant btr_cur_optimistic_update() calls?
[4 Aug 2011 16:37]
Sveta Smirnova
Nizameddin, status "Verified" means behavior reported in the bug report confirmed inside the company. Now it is job of InnoDB team to fix this or explain why this would not be fixed if they decide not to fix.
[13 May 2013 20:38]
Marko Mäkelä
It turns out that the calls are not entirely bogus. There was only one call to known-to-fail btr_cur_optimistic_insert(), in btr_cur_pessimistic_update(). All other callers of btr_cur_pessimistic_insert() would release and reacquire the B-tree page latch before attempting the pessimistic insert. This would allow other threads to restructure the B-tree, allowing the insert to succeed (and requiring the insert to be attempted) as an optimistic (single-page) operation. The fixable case was fixed as part of Bug#61456.