Hi, Nikita, No, in this case (and commonly for collateral changes) I'd rather prefer to refine the original (878a92e) commit to not cause the MDEV-29056 in the first place.
Ignoring LOCK= clause is logically correct and that's what the old code was doing anyway. But perhaps ALTER TABLE still needs to check that ALGORITHM= and LOCK= clauses are compatible? On Aug 27, Nikita Malyavin wrote: > revision-id: ed477a6d30c (mariadb-10.6.1-521-ged477a6d30c) > parent(s): 56206e60315 > author: Nikita Malyavin > committer: Nikita Malyavin > timestamp: 2022-07-26 00:41:00 +0300 > message: > > MDEV-29056 Replica thread reports error on ALTER ONLINE after LOCK WRITE > > Commit 878a92e (MDEV-28943) changes the behavior of ALTER TABLE under > prelocking. It now ignores passed LOCK= value in that case. > > However, LOCK TABLES command is never replicated, so the replica node > remains unaware of it. > > The solution would be to guess on the replica side on the mode used by > master. To make a deduction reliable, master's locked_tables_mode state > is passed for query log events. Regards, Sergei VP of MariaDB Server Engineering and secur...@mariadb.org _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
