Description

FYI for when 8.0.37 merging starts, another INSTANT DDL regression .

Originally reported here which is now private: https://bugs.mysql.com/114837

Summary
Executing a instant DDL followed by a UPDATE will lead to an assertion failure on upstream 8.0.37. Haven't dug into it yet but I suspect it may be related to how INSTANT DDL column ordering issue fixed in 8.0.37

8.0.27 INSTANT DDL Upstream fixes:

InnoDB: The redo log would potentially not log a column order change with instant DDL, which could cause an incorrect log replay during recovery. (Bug #35183686)

8-0-37 tag is not on github yet but here is the 8.4.0 fix:

Bug: https://bugs.mysql.com/bug.php?id=113442

There was also this instant fix related to instant, which has been in innovation release since 8.2:

  • InnoDB: If a MySQL table in a system schema had an INSTANT ADD column that was added before 8.0.29 (they are not allowed as of that version), and after MySQL was upgraded to a version greater than 8.0.29, DMLs on these tables would result in the server unexpectedly closing.

    Our thanks to Richard Dang for the contribution. (Bug #35625510, Bug #35981565, Bug #36180360)

Bug:

Repro

Note that rebuilding the table post restart seems to resolve this specific INSTANT ddl operation.

stack

2024-05-01T14:42:37.896516Z 9 [ERROR] [MY-013183] [InnoDB] Assertion failure: mtr0log.cc:647:total > (ulint)(log_ptr - log_start) thread 139646299346496
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-05-01T14:42:37Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=760904bb5c412602b3f2c1b7241648b1a2970a7b
Thread pointer: 0x7f01a0011e70
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f01f0110b30 thread_stack 0x100000
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x21211bd]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(print_fatal_signal(int)+0x37f) [0xfe111f]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(my_server_abort()+0x7e) [0xfe126e]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(my_abort()+0xa) [0x211b38a]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x31f) [0x233cc5f]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld() [0x2245028]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(mlog_open_and_write_index(mtr_t*, unsigned char const*, dict_index_t const*, mlog_id_t, unsigned long, unsigned char*&)+0x982) [0x2247802]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(page_cur_delete_rec(page_cur_t*, dict_index_t const*, unsigned long const*, mtr_t*)+0x108) [0x2262ee8]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(btr_cur_pessimistic_update(unsigned long, btr_cur_t*, unsigned long*, mem_block_info_t, mem_block_info_t, big_rec_t*, upd_t, unsigned long, que_thr_t*, unsigned long, unsigned long, mtr_t*, btr_pcur_t*)+0x6de) [0x237a26e]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld() [0x22d0ea9]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld() [0x22d1759]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(row_upd_step(que_thr_t*)+0xb5c) [0x22d490c]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld() [0x22a1f51]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(ha_innobase::update_row(unsigned char const*, unsigned char*)+0x360) [0x218c6c0]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(handler::ha_update_row(unsigned char const*, unsigned char*)+0x20b) [0x10f474b]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(Sql_cmd_update::update_single_table(THD*)+0x1d0d) [0xf5758d]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(Sql_cmd_dml::execute(THD*)+0x1e4) [0xecce64]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(mysql_execute_command(THD*, bool)+0xb3f) [0xe7310f]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x520) [0xe76da0]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0xdee) [0xe7813e]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld(do_command(THD*)+0x21e) [0xe7a51e]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld() [0xfd13e8]
/home/ec2-user/opt/mysql/8.0.37/bin/mysqld() [0x27c86e5]
/lib64/libc.so.6(+0x9f7f2) [0x7f021b29f7f2]
/lib64/libc.so.6(+0x3f450) [0x7f021b23f450]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f01a025e740): UPDATE t1 SET c4 = 'value' WHERE c1 = 'k1'
Connection ID (thread ID): 9
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Forcing INPLACE DDL does not crash

Environment

None

Activity

Show:

Satya Bodapati June 27, 2024 at 2:10 PM

Pasting the slack discussion here:

Yura Sorokin June 25, 2024 at 9:58 PM

Yura Sorokin May 20, 2024 at 12:06 PM

Aaditya Dubey May 2, 2024 at 9:44 AM

Hi

Thank you for the report.
Verified as described.

marc reilly May 1, 2024 at 4:50 PM

8.4.0 stack for search-ability:

Done
Pinned fields
Click on the next to a field label to start pinning.
Details

Assignee

Varun Arakere Nagaraju

Reporter

marc reilly

Regression Issue

Yes

Upstream Bug URL

Needs QA

Yes

Sprint

None

Affects versions

Priority

Smart Checklist
Created May 1, 2024 at 3:48 PM
Updated August 28, 2024 at 2:26 PM
Resolved July 5, 2024 at 11:55 AM
Loading...