Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL)
-
None
Description
10.2 debug 7c85a8d936b1a |
mysqld: /data/src/10.2/storage/innobase/row/row0log.cc:2432: const mrec_t* row_log_table_apply_op(que_thr_t*, ulint, ulint, row_merge_dup_t*, dberr_t*, mem_heap_t*, mem_heap_t*, const mrec_t*, const mrec_t*, ulint*): Assertion `0' failed.
|
171109 2:35:13 [ERROR] mysqld got signal 6 ;
|
|
#7 0x00007f9135c14ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
|
#8 0x000055c43656a131 in row_log_table_apply_op (thr=0x7f90d4024510, trx_id_col=1, new_trx_id_col=1, dup=0x7f913009e2e0, error=0x7f913009e084, offsets_heap=0x7f90d404ce70, heap=0x7f90d4028540, mrec=0x7f912869206d "\002B\001", mrec_end=0x7f9128692094 "", offsets=0x7f90d4025900) at /data/src/10.2/storage/innobase/row/row0log.cc:2432
|
#9 0x000055c43656c1b3 in row_log_table_apply_ops (thr=0x7f90d4024510, dup=0x7f913009e2e0, stage=0x7f90d4026120) at /data/src/10.2/storage/innobase/row/row0log.cc:3085
|
#10 0x000055c43656c6be in row_log_table_apply (thr=0x7f90d4024510, old_table=0x7f90e0091918, table=0x7f90d4019800, stage=0x7f90d4026120) at /data/src/10.2/storage/innobase/row/row0log.cc:3184
|
#11 0x000055c436450912 in ha_innobase::inplace_alter_table (this=0x7f90e014ed58, altered_table=0x7f90d4019800, ha_alter_info=0x7f913009e610) at /data/src/10.2/storage/innobase/handler/handler0alter.cc:6464
|
#12 0x000055c435f6948b in handler::ha_inplace_alter_table (this=0x7f90e014ed58, altered_table=0x7f90d4019800, ha_alter_info=0x7f913009e610) at /data/src/10.2/sql/handler.h:3768
|
#13 0x000055c435f60705 in mysql_inplace_alter_table (thd=0x7f90d4000b00, table_list=0x7f90d4011170, table=0x7f90e014e150, altered_table=0x7f90d4019800, ha_alter_info=0x7f913009e610, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f913009e680, alter_ctx=0x7f913009f240) at /data/src/10.2/sql/sql_table.cc:7332
|
#14 0x000055c435f65a47 in mysql_alter_table (thd=0x7f90d4000b00, new_db=0x7f90d4011780 "test", new_name=0x0, create_info=0x7f913009fe50, table_list=0x7f90d4011170, alter_info=0x7f913009fda0, order_num=0, order=0x0, ignore=false) at /data/src/10.2/sql/sql_table.cc:9324
|
#15 0x000055c435fdeb38 in Sql_cmd_alter_table::execute (this=0x7f90d4011790, thd=0x7f90d4000b00) at /data/src/10.2/sql/sql_alter.cc:324
|
#16 0x000055c435e9b139 in mysql_execute_command (thd=0x7f90d4000b00) at /data/src/10.2/sql/sql_parse.cc:6189
|
#17 0x000055c435e9f9ea in mysql_parse (thd=0x7f90d4000b00, rawbuf=0x7f90d4011088 "ALTER TABLE t1 ENGINE=InnoDB", length=28, parser_state=0x7f91300a1200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7861
|
#18 0x000055c435e8d9a6 in dispatch_command (command=COM_QUERY, thd=0x7f90d4000b00, packet=0x7f90d40088a1 "ALTER TABLE t1 ENGINE=InnoDB", packet_length=28, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1805
|
#19 0x000055c435e8c304 in do_command (thd=0x7f90d4000b00) at /data/src/10.2/sql/sql_parse.cc:1360
|
#20 0x000055c435fd9829 in do_handle_one_connection (connect=0x55c439414780) at /data/src/10.2/sql/sql_connect.cc:1354
|
#21 0x000055c435fd95b6 in handle_one_connection (arg=0x55c439414780) at /data/src/10.2/sql/sql_connect.cc:1260
|
#22 0x000055c4363f6aac in pfs_spawn_thread (arg=0x55c4394af1d0) at /data/src/10.2/storage/perfschema/pfs.cc:1863
|
#23 0x00007f91378eb494 in start_thread (arg=0x7f91300a2700) at pthread_create.c:333
|
#24 0x00007f9135cd193f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
10.2 non-debug 7c85a8d936b1a |
CREATE TABLE t1 (c CHAR(8), i INT, v INT AS (i) VIRTUAL) ENGINE=InnoDB;
|
INSERT INTO t1 (c,i) VALUES ('foo',1),('bar',2);
|
connect con1,localhost,root,,test;
|
ALTER TABLE t1 ENGINE=InnoDB;
|
connect con2,localhost,root,,test;
|
ALTER TABLE t1 ADD f INT;
|
connection default;
|
BEGIN;
|
UPDATE t1 SET i = 0;
|
ROLLBACK;
|
connection con1;
|
ERROR HY000: Index for table 't1' is corrupt; try to repair it
|
disconnect con1;
|
connection con2;
|
disconnect con2;
|
connection default;
|
DROP TABLE t1;
|
10.3 is also affected.
No failure on 10.1.
The test case is concurrent, but it fails quite reliably for me. Still, if it doesn't fail right away, try running with --repeat=N.
--source include/have_innodb.inc
|
|
CREATE TABLE t1 (c CHAR(8), i INT, v INT AS (i) VIRTUAL) ENGINE=InnoDB; |
INSERT INTO t1 (c,i) VALUES ('foo',1),('bar',2); |
|
--connect (con1,localhost,root,,test)
|
--send
|
ALTER TABLE t1 ENGINE=InnoDB; |
|
--connect (con2,localhost,root,,test)
|
--send
|
ALTER TABLE t1 ADD f INT; |
|
--connection default
|
BEGIN; |
UPDATE t1 SET i = 0; |
ROLLBACK; |
|
# Cleanup
|
|
--connection con1
|
--reap
|
--disconnect con1
|
--connection con2
|
--reap
|
--disconnect con2
|
--connection default
|
DROP TABLE t1; |
Attachments
Issue Links
- blocks
-
MDEV-31087 Merge new release of InnoDB 5.7.42 to 10.3
- Closed
- causes
-
MDEV-14341 Allow LOCK=NONE in table-rebuilding ALTER when indexed virtual columns exist
- Open
- includes
-
MDEV-13795 ALTER TABLE…DROP PRIMARY KEY, ADD PRIMARY KEY fails when VIRTUAL columns exist
- Closed
- relates to
-
MDEV-5800 indexes on virtual (not materialized) columns
- Closed
-
MDEV-13795 ALTER TABLE…DROP PRIMARY KEY, ADD PRIMARY KEY fails when VIRTUAL columns exist
- Closed
-
MDEV-16329 Engine-independent online ALTER TABLE
- Closed