Hi!

On Fri, 17 Apr 2020, 15:21 Sergei Golubchik, <serg@mariadb.org> wrote:
Hi, Michael!

On Apr 16, Michael Widenius wrote:
> Hi!
>
> On Thu, Apr 16, 2020 at 1:17 PM Sergei Golubchik <serg@mariadb.org> wrote:
>
> <cut>
> > where's a test case for MDEV-22077?
>
> One can't use the test case in MDEV-22077 as it involves a table
> created by a 32 bit MariaDB version. Doing another test case it's very
> hard so I ignored it and just did run the test to verify the patch.

Alice posted a simple test case in the comments.
It has a very similar stack trace.
Could you check it out? Is it a same bug or a different one?

> > > diff --git a/sql/sql_delete.cc b/sql/sql_delete.cc
> > > index 19eabbb053c..2fc0de4345f 100644
> > > --- a/sql/sql_delete.cc
> > > +++ b/sql/sql_delete.cc
> > > @@ -547,10 +547,12 @@ bool mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds,
> > >      else
> > >      {
> > >        ha_rows scanned_limit= query_plan.scanned_rows;
> > > +      table->no_keyread= 1;
> > >        query_plan.index= get_index_for_order(order, table, select, limit,
> > >                                              &scanned_limit,
> > >                                              &query_plan.using_filesort,
> > >                                              &reverse);
> > > +      table->no_keyread= 0;
> >
> > why?
>
> get_index_for_order is not allowed to change to use key_reads as there
> is no guarantee
> at this point that the suggested index will be used. That was the
> reason we got crashes.

Why does it enable keyread then? Where?

Don't know exactly and don't care for the moment.  The problem is that we try to do a last desperate attempt to use a better index after all optimization decissions are already done and this is an effect of this.
Changing this is too time consuming at this point (been in discussions for years and not done already as it's not trivial) so I don't have time to do it now.

Regards,
Monty