Sergei, On Wed, Sep 1, 2021 at 8:51 PM Sergei Golubchik <s...@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 secur...@mariadb.org -- All the best, Aleksey Midenkov @midenok
z.test
Description: Binary data
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp