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 security@mariadb.org