← Back to team overview

maria-developers team mailing list archive

Re: 6768e3a2830: MDEV-22166 MIGRATE PARTITION: move out partition into a table

 

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?

> 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.

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@xxxxxxxxxxx


Follow ups

References