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