On Wed, 9 Aug 2023 at 15:28, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Nikita,
On Aug 08, Nikita Malyavin wrote:
It doesn't just avoid sql_command reset: look through the slave_exec_mode usage -- it does a few things that can have side-effects. Better to avoid it altogether and keep our execution flow away from interactions with replication switches.
ok
The assertion I've added doesn't fail, so no, only IDEMPOTENT inserts do this.
Yes, I didn't mean other events do it. I only said that it's fragile to assume they won't do it in the future (and that I've seen an unpushed commit that changes it).
Maybe there's a way to avoid it? In system versioning we first used sql_command to determine ha_delete_row role, but recently we began using trg_event_map for that, which also simplified the code. Maybe some detection improvement is also possible in the case you mention?
But ok, if it'll change in the future your assert will catch it.
By the way, should be it SQLCOM_ALTER_TABLE? Or safer to save the old value and restore it? Can OPTIMIZE or something come down this code path?
Thanks for the pointer! I'll better write it in a safer way. Online is disabled for OPTIMIZE at this moment. Does it make sense otherwise? I know nothing about it. And I'm not aware of any other command that can go there.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
-- Yours truly, Nikita Malyavin