maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

Sergei,

On Wed, Sep 1, 2021 at 8:51 PM Sergei Golubchik <serg@xxxxxxxxxxx> 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@xxxxxxxxxxx



-- 
All the best,

Aleksey Midenkov
@midenok

Attachment: z.test
Description: Binary data