Sergei, On Wed, Sep 1, 2021 at 8:51 PM Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Aleksey!
On Aug 27, Aleksey Midenkov wrote:
I still don't quite understand why did you introduce a new method with frm backup and a (low probability) window where it won't clean up.
Isn't it similar to normal ALTER TABLE? It also needs to replace frms and it is solved with ddl log - if a crash happens after the point of no return (after the frm was replaced with a new one), ddl log will binlog the query on recovery.
Could you do the same, like
case DDL_LOCK_MIGRATE_PARTITION_ACTION: if (shadow frm no longer exists && xid not in binlog) write_bin_log(...);
would that work? Or would partitioning-specific old ddl logging code interfere?
I believe ALTER TABLE atomicity is not the perfect one in respect of rollback on error so why should that be an example for me?
let's start from a statement. You're stating that ALTER TABLE atomicity is not the perfect one in respect of rollback on error.
What do you mean by that? Can you show how ALTER TABLE wouldn't be atomic after a rollback on an error?
An example test is attached to this email.
Another issue with the scheme you proposed is worse complexity and reliability.
It's the scheme that ALTER TABLE and other DDL statements are using now. If you have something simpler and more reliable, could you please describe it so that we could change all DDL statements to use your approach?
Why do I have to do some vague logic about binlogging if it can be straightforward and simple? So either I have to expand frm handling or add another DDL log action: why are you asking me not to do the former and do the latter?
Because - as far as I understand - the latter is what all other DDL statements use, except old partitioning statements that weren't converted yet.
we really do not want *three* different approaches to atomicity in the same ALTER TABLE statement. It's just not maintainable.
I guess partitioning has no approach for that, the best it does is printing the warning message. So it is 2 of them. And partitioning can be easily switched to my scheme. As for the other DDL, it should be simplified as well, I hope this is possible. But as an intermediate we can have 2 approaches: for partitioning (my scheme) and for other DDL.
But perhaps I misunderstood and DDL atomicity was implemented differently from what I've described? Then I'm sorry, I didn't intend to suggest that you should implement yet another approach to DDL atomicity, I was saying, please, do what other statements do.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
-- All the best, Aleksey Midenkov @midenok