[MDEV-20370] Assertion `mtr->get_log_mode() == MTR_LOG_NO_REDO' failed in page_cur_insert_rec_write_log with innodb_defragment=ON Created: 2019-08-17  Updated: 2020-03-31  Resolved: 2020-03-17

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Temporary, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.2.32, 10.3.23, 10.4.13, 10.5.2

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: affects-tests

Issue Links:
Duplicate
is duplicated by MDEV-21757 Assertion `purpose == FIL_TYPE_TABLES... Closed

 Description   

--source include/have_sequence.inc
--source include/have_innodb.inc
 
SET GLOBAL innodb_defragment=ON;
 
CREATE TEMPORARY TABLE t (a INT) ENGINE=InnoDB;
INSERT INTO t SELECT seq FROM seq_1_to_800;
OPTIMIZE TABLE t;

10.2 29e560cd

mysqld: /data/src/10.2/storage/innobase/page/page0cur.cc:857: void page_cur_insert_rec_write_log(const rec_t*, ulint, const rec_t*, dict_index_t*, mtr_t*): Assertion `mtr->get_log_mode() == MTR_LOG_NO_REDO' failed.
190817 17:45:52 [ERROR] mysqld got signal 6 ;
 
#6  0x00007f67c0065e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55ff193560d0 "mtr->get_log_mode() == MTR_LOG_NO_REDO", file=file@entry=0x55ff19355f28 "/data/src/10.2/storage/innobase/page/page0cur.cc", line=line@entry=857, function=function@entry=0x55ff19357ae0 <page_cur_insert_rec_write_log(unsigned char const*, unsigned long, unsigned char const*, dict_index_t*, mtr_t*)::__PRETTY_FUNCTION__> "void page_cur_insert_rec_write_log(const rec_t*, ulint, const rec_t*, dict_index_t*, mtr_t*)") at assert.c:92
#7  0x00007f67c0065f12 in __GI___assert_fail (assertion=0x55ff193560d0 "mtr->get_log_mode() == MTR_LOG_NO_REDO", file=0x55ff19355f28 "/data/src/10.2/storage/innobase/page/page0cur.cc", line=857, function=0x55ff19357ae0 <page_cur_insert_rec_write_log(unsigned char const*, unsigned long, unsigned char const*, dict_index_t*, mtr_t*)::__PRETTY_FUNCTION__> "void page_cur_insert_rec_write_log(const rec_t*, ulint, const rec_t*, dict_index_t*, mtr_t*)") at assert.c:101
#8  0x000055ff18cc42c1 in page_cur_insert_rec_write_log (insert_rec=0x7f67bae8007e "", rec_size=29, cursor_rec=0x7f67bae80063 "infimum", index=0x7f676800a738, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/page/page0cur.cc:857
#9  0x000055ff18cc6008 in page_cur_insert_rec_low (current_rec=0x7f67bae80063 "infimum", index=0x7f676800a738, rec=0x7f67bae8c07e "", offsets=0x7f678bffdb90, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/page/page0cur.cc:1448
#10 0x000055ff18ccd2fa in page_copy_rec_list_end_no_locks (new_block=0x7f67ba9868e0, block=0x7f67ba987228, rec=0x7f67bae8c063 "infimum", index=0x7f676800a738, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/page/page0page.cc:612
#11 0x000055ff18e1600f in btr_page_reorganize_low (recovery=false, z_level=6, cursor=0x7f678bffe2d0, index=0x7f676800a738, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/btr/btr0btr.cc:1529
#12 0x000055ff18e16811 in btr_page_reorganize_block (recovery=false, z_level=6, block=0x7f67ba9868e0, index=0x7f676800a738, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/btr/btr0btr.cc:1687
#13 0x000055ff18e59244 in btr_defragment_merge_pages (index=0x7f676800a738, from_block=0x7f67ba986bf8, to_block=0x7f67ba9868e0, page_size=..., reserved_space=580, max_data_size=0x7f678bffe4c8, heap=0x7f676c000b90, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/btr/btr0defragment.cc:419
#14 0x000055ff18e59d4b in btr_defragment_n_pages (block=0x7f67ba9868e0, index=0x7f676800a738, n_pages=3, mtr=0x7f678bffe9f0) at /data/src/10.2/storage/innobase/btr/btr0defragment.cc:670
#15 0x000055ff18e5a05a in btr_defragment_thread () at /data/src/10.2/storage/innobase/btr/btr0defragment.cc:766
#16 0x00007f67c1bda4a4 in start_thread (arg=0x7f678bfff700) at pthread_create.c:456
#17 0x00007f67c0122d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

No obvious effect on a non-debug build.



 Comments   
Comment by Marko Mäkelä [ 2020-03-17 ]

The defragmenting code must definitely skip temporary tables. The tables are typically short-lived, and temporary tables are assumed to be accessed only by the thread that is handling the owning connection.

Generated at Thu Feb 08 08:58:57 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.