Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.6, 10.11, 11.4, 11.8, 12.3
-
None
-
Can result in hang or crash
-
Fixed a server assertion that occurred when an InnoDB DDL operation (such as ALTER TABLE) encountered a lock wait timeout during internal statistics updates.
-
Q1/2026 Server Development
Description
MDEV-35163 introduced a regression in 10.6.24 and corresponding releases of other release lines. It was reported as MDEV-38667, but it was only partially fixed in 10.6.25 – one of two test cases in the description still fails with the same symptoms on current post-10.6.25 builds.
The test case is non-deterministic, but it is fast and fails easily – too easily, it badly affects concurrent tests on debug builds – so, please run it with sufficient --repeat=N and fix it.
Same test case as in MDEV-38667, I only removed LOCK=NONE which 10.6 complains about (the test case was originally for 11.4, as the stack trace in MDEV-38667 indicates).
--source include/have_innodb.inc
|
|
|
CREATE TABLE t1 (a INT) ENGINE=InnoDB; |
CREATE TABLE t2 (pk INT PRIMARY KEY) ENGINE=InnoDB; |
|
|
--connect (con1,localhost,root,,)
|
--send
|
ALTER TABLE t1 NOWAIT FORCE, ALGORITHM=COPY; |
--connection default
|
ALTER TABLE t2 FORCE, ALGORITHM=COPY; |
|
|
--connection con1
|
--error 0,ER_LOCK_WAIT_TIMEOUT
|
--reap
|
|
|
DROP TABLE t1, t2; |
|
10.6 1758b2578a8cc7e193bb35de0d8dc9a5e517c89c |
mariadbd: /data/bld/10.6-asan-ubsan/sql/sql_error.cc:347: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
|
|
|
#10 0x00007f37d9c53eb2 in __GI___assert_fail (assertion=0x5591e1143fa0 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x5591e1144f60 "/data/bld/10.6-asan-ubsan/sql/sql_error.cc", line=347, function=0x5591e1144000 "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at ./assert/assert.c:101
|
#11 0x00005591dd735687 in Diagnostics_area::set_ok_status (this=this@entry=0x62b0000e61f8, affected_rows=affected_rows@entry=0, last_insert_id=last_insert_id@entry=0, message=message@entry=0x7f37c8eab0a0 "Records: 0 Duplicates: 0 Warnings: 1") at /data/bld/10.6-asan-ubsan/sql/sql_error.cc:347
|
#12 0x00005591dd590c7e in my_ok (thd=thd@entry=0x62b0000e0218, affected_rows_arg=0, id=id@entry=0, message=message@entry=0x7f37c8eab0a0 "Records: 0 Duplicates: 0 Warnings: 1") at /data/bld/10.6-asan-ubsan/sql/sql_class.h:5884
|
#13 0x00005591dd6cce49 in THD::my_ok_with_recreate_info (this=this@entry=0x62b0000e0218, info=..., warn_count=<optimized out>) at /data/bld/10.6-asan-ubsan/sql/sql_class.cc:8674
|
#14 0x00005591dde14c7d in mysql_alter_table (thd=thd@entry=0x62b0000e0218, new_db=<optimized out>, new_name=new_name@entry=0x62b0000e5330, create_info=create_info@entry=0x7f37c8eae370, table_list=table_list@entry=0x62d0002b28e0, recreate_info=recreate_info@entry=0x7f37c8eae100, alter_info=<optimized out>, order_num=<optimized out>, order=<optimized out>, ignore=<optimized out>, if_exists=<optimized out>) at /data/bld/10.6-asan-ubsan/sql/sql_table.cc:11374
|
#15 0x00005591de1211ef in Sql_cmd_alter_table::execute (this=<optimized out>, thd=0x62b0000e0218) at /data/bld/10.6-asan-ubsan/sql/sql_alter.cc:675
|
#16 0x00005591dd954014 in mysql_execute_command (thd=thd@entry=0x62b0000e0218, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:6168
|
#17 0x00005591dd958580 in mysql_parse (thd=thd@entry=0x62b0000e0218, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7f37c8eafac0) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:8201
|
#18 0x00005591dd96187d in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x62b0000e0218, packet=packet@entry=0x62900095b219 "", packet_length=packet_length@entry=43, blocking=blocking@entry=true) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:1911
|
#19 0x00005591dd96e598 in do_command (thd=thd@entry=0x62b0000e0218, blocking=blocking@entry=true) at /data/bld/10.6-asan-ubsan/sql/sql_parse.cc:1421
|
#20 0x00005591de0f1530 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x608000018a38, put_in_cache=put_in_cache@entry=true) at /data/bld/10.6-asan-ubsan/sql/sql_connect.cc:1386
|
#21 0x00005591de0f268d in handle_one_connection (arg=0x608000018a38) at /data/bld/10.6-asan-ubsan/sql/sql_connect.cc:1298
|
#22 0x00005591dfb24f97 in pfs_spawn_thread (arg=0x617000008218) at /data/bld/10.6-asan-ubsan/storage/perfschema/pfs.cc:2201
|
#23 0x00007f37d9ca81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#24 0x00007f37d9d2885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
Non-debug error (sometimes fails this way on debug builds too):
ER_ALTER_INFO (1088): 'Error updating stats for table after table rebuild: Lock wait timeout'
|
The failure was caused by this commit
commit 687b18648ca41aecb4211f14f6506410a9495f9f
|
Author: Thirunarayanan Balathandayuthapani
|
Date: Mon Sep 22 17:39:47 2025 +0530
|
|
|
MDEV-35163 InnoDB persistent statistics fail to update after ALTER TABLE...ALGORITHM=COPY
|
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
-
- Closed
-