maria-developers team mailing list archive

[Nikita Malyavin <nikitamalyavin@xxxxxxxxx>]

On Fri, Mar 1, 2019 at 1:24 AM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Nikita!
>
> On Feb 28, Nikita Malyavin wrote:
> > On Fri, Dec 28, 2018 at 9:18 AM Sergei Golubchik <serg@xxxxxxxxxxx>
> wrote:
> > > On Dec 28, Nikita Malyavin wrote:
> > > > Hi, Sergei!
> > > >
> > > > In short, I am on the side of standard conformance.
> > >
> > > Our TRUNCATE is not exactly a standard TRUNCATE. it's defined as
> > > DROP+REPLACE. But generally I agree, standard conformance.
> >
> > The fun thing is that even handler::truncate() is defined as
> > delete_all_rows() 🙂
> > Actually even ha_innodb does something same, and frm file is never
> > deleted/touched.
> > So physically it's always deletion of rows data, not DROP + CREATE
> > Maybe I'm missing something, am I?
>
> you are :)
>
> If the handlerton has a flag HTON_CAN_RECREATE, then
> Sql_cmd_truncate_table::lock_table() will set hton_can_recreate
> and Sql_cmd_truncate_table::truncate_table() will use
> dd_recreate_table(), not handler::delete_all_rows()
>
> I know, but it doesn't affect frm.

> > I'd try to remove HTON_CAN_RECREATE flag completely and implement
> > > recreate logic inside handler::delete_all_rows()
> > >
> > > Yes, good idea, I'm thinking the same.
> > So am I supposed to file MDEV for it then?
>
> Yes, please
>
> MDEV-18773

-- 
Yours truly,
Nikita Malyavin