Up to you, I have no straight opinion which way is better. I only think that both ways are manageable.
BTW, why we have no such problem with INPLACE? On Sat, 27 Aug 2022 at 18:11, Sergei Golubchik <s...@mariadb.org> wrote: > 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 > -- Yours truly, Nikita Malyavin
_______________________________________________ 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
