Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4(EOL)
-
None
Description
Notes:
- There is a lot of "back and forth" in the test case with creating/dropping/renaming columns, but I can't get rid of the remaining part without having the outcome changed.
- If I add ALGORITHM=COPY to any of the ALTER statements in the test case, the crash stops happening. Explicit ALGORITHM=INSTANT or ALGORITHM=INPLACE don't seem to change the outcome.
- The test case is concurrent and hence should be non-deterministic. It fails every time for me, but if it doesn't for you, try to run with --repeat.
--source include/have_innodb.inc
|
 |
--connect (con1,localhost,root,,test)
|
--connection default
|
CREATE TABLE t1 (f GEOMETRY DEFAULT POINT(0,0), a INT, b INT, c INT, col INT) ENGINE=InnoDB; |
ALTER TABLE t1 DROP COLUMN a; |
ALTER TABLE t1 DROP COLUMN c; |
ALTER TABLE t1 DROP COLUMN b; |
ALTER TABLE t1 CHANGE COLUMN col b INT; |
ALTER TABLE t1 ADD COLUMN col INT; |
ALTER TABLE t1 DROP COLUMN b; |
ALTER TABLE t1 CHANGE COLUMN col b INT; |
ALTER TABLE t1 ADD COLUMN col INT; |
ALTER TABLE t1 DROP COLUMN b ; |
ALTER TABLE t1 CHANGE COLUMN col b INT; |
INSERT INTO t1 () VALUES (); |
 |
SET SQL_MODE= ''; |
--send
|
ALTER TABLE t1 ADD PRIMARY KEY(b); |
 |
--connection con1
|
PREPARE stmt FROM 'UPDATE t1 SET b = 1'; |
EXECUTE stmt; |
 |
# Cleanup
|
DEALLOCATE PREPARE stmt; |
--disconnect con1
|
 |
--connection default
|
--reap
|
DROP TABLE t1; |
10.4 574354a6 |
mysqld: /data/src/10.4/storage/innobase/row/row0log.cc:2121: dberr_t row_log_table_apply_update(que_thr_t*, ulint, const mrec_t*, const offset_t*, mem_heap_t*, mem_heap_t*, row_merge_dup_t*, const dtuple_t*): Assertion `log->blobs' failed.
|
200204 14:18:35 [ERROR] mysqld got signal 6 ;
|
 |
#7 0x00007f0d897a5f12 in __GI___assert_fail (assertion=0x5562839cee4a "log->blobs", file=0x5562839ce248 "/data/src/10.4/storage/innobase/row/row0log.cc", line=2121, function=0x5562839d1f40 <row_log_table_apply_update(que_thr_t*, unsigned long, unsigned char const*, unsigned short const*, mem_block_info_t*, mem_block_info_t*, row_merge_dup_t*, dtuple_t const*)::__PRETTY_FUNCTION__> "dberr_t row_log_table_apply_update(que_thr_t*, ulint, const mrec_t*, const offset_t*, mem_heap_t*, mem_heap_t*, row_merge_dup_t*, const dtuple_t*)") at assert.c:101
|
#8 0x00005562831a3c54 in row_log_table_apply_update (thr=0x7f0d381ae4a8, new_trx_id_col=1, mrec=0x7f0d7e8fe016 "", offsets=0x7f0d381a24e0, offsets_heap=0x7f0d381d7460, heap=0x7f0d381d33d0, dup=0x7f0d8414bcf0, old_pk=0x7f0d381d3458) at /data/src/10.4/storage/innobase/row/row0log.cc:2121
|
#9 0x00005562831a5dcb in row_log_table_apply_op (thr=0x7f0d381ae4a8, new_trx_id_col=1, dup=0x7f0d8414bcf0, error=0x7f0d8414ba6c, offsets_heap=0x7f0d381d7460, heap=0x7f0d381d33d0, mrec=0x7f0d7e8fe016 "", mrec_end=0x7f0d7e8fe045 "", offsets=0x7f0d381a24e0) at /data/src/10.4/storage/innobase/row/row0log.cc:2664
|
#10 0x00005562831a7fe1 in row_log_table_apply_ops (thr=0x7f0d381ae4a8, dup=0x7f0d8414bcf0, stage=0x7f0d381b1340) at /data/src/10.4/storage/innobase/row/row0log.cc:3037
|
#11 0x00005562831a873d in row_log_table_apply (thr=0x7f0d381ae4a8, old_table=0x7f0d3800be58, table=0x7f0d8414c800, stage=0x7f0d381b1340, new_table=0x7f0d381aed98) at /data/src/10.4/storage/innobase/row/row0log.cc:3143
|
#12 0x000055628302ded0 in ha_innobase::inplace_alter_table (this=0x7f0d38066ed8, altered_table=0x7f0d8414c800, ha_alter_info=0x7f0d8414c770) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:8379
|
#13 0x0000556282b2d9ff in handler::ha_inplace_alter_table (this=0x7f0d38066ed8, altered_table=0x7f0d8414c800, ha_alter_info=0x7f0d8414c770) at /data/src/10.4/sql/handler.h:4361
|
#14 0x0000556282b21a91 in mysql_inplace_alter_table (thd=0x7f0d38000af0, table_list=0x7f0d38013288, table=0x7f0d38066070, altered_table=0x7f0d8414c800, ha_alter_info=0x7f0d8414c770, inplace_supported=HA_ALTER_INPLACE_COPY_NO_LOCK, target_mdl_request=0x7f0d8414d5d0, alter_ctx=0x7f0d8414e100) at /data/src/10.4/sql/sql_table.cc:7725
|
#15 0x0000556282b28953 in mysql_alter_table (thd=0x7f0d38000af0, new_db=0x7f0d380052b0, new_name=0x7f0d380056b8, create_info=0x7f0d8414ecf0, table_list=0x7f0d38013288, alter_info=0x7f0d8414ec30, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:10119
|
#16 0x0000556282bc0a47 in Sql_cmd_alter_table::execute (this=0x7f0d38013a18, thd=0x7f0d38000af0) at /data/src/10.4/sql/sql_alter.cc:508
|
#17 0x0000556282a3f221 in mysql_execute_command (thd=0x7f0d38000af0) at /data/src/10.4/sql/sql_parse.cc:6102
|
#18 0x0000556282a448e3 in mysql_parse (thd=0x7f0d38000af0, rawbuf=0x7f0d38013198 "ALTER TABLE t1 ADD PRIMARY KEY(b)", length=33, parser_state=0x7f0d84150160, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
|
#19 0x0000556282a2fab0 in dispatch_command (command=COM_QUERY, thd=0x7f0d38000af0, packet=0x7f0d381371b1 "ALTER TABLE t1 ADD PRIMARY KEY(b)", packet_length=33, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
|
#20 0x0000556282a2e13d in do_command (thd=0x7f0d38000af0) at /data/src/10.4/sql/sql_parse.cc:1360
|
#21 0x0000556282bb7357 in do_handle_one_connection (connect=0x556285d28b80) at /data/src/10.4/sql/sql_connect.cc:1412
|
#22 0x0000556282bb70a6 in handle_one_connection (arg=0x556285d28b80) at /data/src/10.4/sql/sql_connect.cc:1316
|
#23 0x00005562835bfb45 in pfs_spawn_thread (arg=0x556285c47b30) at /data/src/10.4/storage/perfschema/pfs.cc:1869
|
#24 0x00007f0d8b72e4a4 in start_thread (arg=0x7f0d84151700) at pthread_create.c:456
|
#25 0x00007f0d89862d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
Reproducible on 10.4 and 10.5.
Not reproducible on 10.3 with the provided test case (although I do have a record of a similar failure on a 10.3 build).
Only reproducible with UPDATE executed as a prepared statement.
Non-debug build doesn't crash, but it produces an error which I wouldn't expect:
mysqltest: At line 31: query 'reap' failed: 1062: Duplicate entry '0' for key 'PRIMARY' |
The table only has one row, so duplicate key error doesn't make sense to me.
Attachments
Issue Links
- is caused by
-
MDEV-15562 Instant DROP COLUMN or changing the order of columns
- Closed
- is duplicated by
-
MDEV-21660 Unexpected ER_INVALID_USE_OF_NULL upon concurrent UPDATE and ALTER
- Closed