On Wed, 9 Aug 2023 at 15:28, Sergei Golubchik <s...@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 secur...@mariadb.org > -- Yours truly, Nikita Malyavin
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
