maria-developers team mailing list archive

[Nikita Malyavin <nikitamalyavin@xxxxxxxxx>]

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 <serg@xxxxxxxxxxx> 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 security@xxxxxxxxxxx
>


-- 
Yours truly,
Nikita Malyavin