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