Hi, Nikita, As we've discussed on slack, this is wrong. The (serialized) behavior should be as if all DML happened before ALTER. Because if some DML would've happened after ALTER, it would be able to see the new table definition and refer to new columns. On Oct 24, Nikita Malyavin wrote:

revision-id: 152295d1cb1 (mariadb-10.6.1-525-g152295d1cb1) parent(s): 90274a7428e author: Nikita Malyavin committer: Nikita Malyavin timestamp: 2022-10-14 23:17:59 +0300 message:

rpl: extra DEFAULTs should not be UPDATEd

diff --git a/sql/log_event_server.cc b/sql/log_event_server.cc index 25705d13641..a72005d70ab 100644 --- a/sql/log_event_server.cc +++ b/sql/log_event_server.cc @@ -8832,11 +8832,17 @@ Update_rows_log_event::do_exec_row(rpl_group_info *rgi) message= thd->wsrep_info; #endif /* WSREP_PROC_INFO */

- /* this also updates m_curr_row_end */ thd_proc_info(thd, message); - if (unlikely((error= unpack_current_row(rgi, &m_cols_ai)))) + Field **default_field= m_table->default_field; + m_table->default_field= NULL; + /* this also updates m_curr_row_end */ + error= unpack_current_row(rgi, &m_cols_ai); + m_table->default_field= default_field; + + if (unlikely(error)) goto err;

Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org