Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.6
Description
After the changes made in the scope of MDEV-515, this basic scenario will no longer work:
--source include/have_innodb.inc
|
create table t1 (pk int primary key) engine=InnoDB; |
start transaction; |
insert into t1 values (1); |
--connect (con1,localhost,root,,)
|
insert into t1 values (2); |
The second INSERT, which in earlier versions is instant, will now hang until the first connection finishes the transaction (or will time out if it doesn't happen within the timeout interval).
While the locking change was clearly intentional and explicitly mentioned at least in the commit comment to MDEV-515 patch, I still file it as a bug, because I think the negative effect of this change may by far exceed the improvements that MDEV-515 introduces.
The scope of MDEV-515 is a performance improvement of a very big LOAD DATA or INSERT SELECT into an empty table – big enough to make this performance improvement significant from the practical perspective. While certainly important, it is still a rather specific use case, and the gain is limited to faster execution.
On the other hand, "create/empty a table and start using it concurrently" scenario above is as basic as it gets; and the loss can be not only in performance (in case the first transaction is reasonably fast and other ones are just delayed), but in more extreme cases, when the first transaction remains open for a long time, it can render the application non-functional – everything else will be failing with timeouts.
The problem can be happening anywhere within an application, both in business logic and deep in maintenance/service jobs.
It will represent as seemingly sporadic not reproducible weird delays and timeouts and will be nearly impossible to investigate – and even if the cause happens to be revealed, changing this logic in all existing applications won't be realistic.
I don't think that even a possibility to "opt-out" the new behavior would be sufficient, as users are generally not aware of details of the internal implementation of applications they use, as well as database admins if, for example, they maintain a shared hosting.
Attachments
Issue Links
- blocks
-
MDEV-24993 pymysql - executemany test failing - lock timeout - insert wait on non-indexed table
- Closed
- causes
-
MDEV-25297 InnoDB: Failing assertion: trx->roll_limit <= trx->undo_no in trx_rollback_start
- Closed
-
MDEV-25315 Assertion `ptr' failed in ut_align_down | SIGSEGV in dict_table_t::not_redundant | Assertion `!lock_sys_t::get_first(receiver_cell, receiver_id, receiver_heap_no)' failed in lock_rec_move
- Closed
-
MDEV-25401 Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status on SAVEPOINT
- Closed
-
MDEV-25496 Assertion `trx->bulk_insert' failed in trx_undo_report_row_operation on INSERT
- Closed
-
MDEV-25534 Assertion `lock_table_has(trx, index->table, LOCK_IX)' failed in lock_rec_insert_check_and_lock on INSERT
- Closed
-
MDEV-26121 [Note] InnoDB: Resetting invalid page [page id: space=5, page number=3] type 17855 to 6.
- Closed
- is caused by
-
MDEV-515 innodb bulk insert
- Closed
- relates to
-
MDEV-24859 Assertion `static_cast<ins_node_t*>(thr->run_node)->bulk_insert' failed in trx_undo_report_row_operation
- Closed
-
MDEV-24914 Assertion `lock_rec_get_first( lock_hash, receiver, receiver_heap_no) == __null || lock_hash == &lock_sys.prdt_hash || lock_hash == &lock_sys.prdt_page_hash' failed in lock_rec_move_low
- Closed
-
MDEV-25036 use bulk insert optimization for multiple insert statements
- Open
-
MDEV-28327 InnoDB persistent statistics fail to update after bulk insert
- Closed
-
MDEV-29545 InnoDB replace statement returns "can't find record" error during bulk insert operation.
- Closed
-
MDEV-30063 InnoDB: Failing assertion: ib_table->stat_initialized in ha_innobase::info_low()
- Open
-
MDEV-30173 Document magic 10.6+ spell for faster data loading
- Open
-
MDEV-31985 IGNORE in INSERT and LOAD are being ignored in InnoDB bulk insert
- Confirmed
-
MDEV-31835 LOAD DATA into InnoDB w/partitions: huge performance loss, affected 10.6+
- Closed
-
MDEV-32250 To benefit from MDEV-515 , please make option --no-autocommit default in mysqldump from 10.6 onwards
- Open
- mentioned in
-
Page Loading...