maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Rucha!

On Jul 30, Rucha Deodhar wrote:
> > >
> > > -  if ((level == Sql_condition::WARN_LEVEL_WARN) &&
> > > -      really_abort_on_warning())
> > > +  if ((killed == NOT_KILLED) && (level == Sql_condition::WARN_LEVEL_WARN) &&
> > > +       really_abort_on_warning())
> >
> > I don't understand this. I presume the assert that fails is in
> > da->set_error_status(), called below as
> >
> > Yes, the assertion fails in set_error_status().
> 
> >     if (!da->is_error())
> >     {
> >       set_row_count_func(-1);
> >       da->set_error_status(sql_errno, msg, sqlstate, cond);
> >     }
> >
> > but if(!da->is_error()) should prevent set_error_status() from being
> > called when it would need to overwrite the status. So how comes it is
> > still called and triggers the assert?
> 
> The status does not change to DA_ERROR yet, it changes in
> set_error_status(), so !thd->is_error() becomes true and does not prevent
> set_error_status() from being called. The reason we get assertion failure
> in set_error_status() is because !is_set() is false (because status is
> DA_OK) and m_can_overwrite_status is false too.

I see.

I also was confused by how can THD::raise_condition() be called
after the status is already DA_OK? An error should not happen after
DA_OK.

But it turns out it was not just any error, it was push_warning() with
the message "Query execution was interrupted. The query examined at
least 4 rows, which exceeds LIMIT ROWS EXAMINED (2). The query result
may be incomplete". This warning should not be converted to an error,
obviously.

It is converted, because thd->abort_on_warning is true. It's set to true
in select_insert::prepare().

And the warning is pushed in handle_select(). Perhaps this warning
should never have thd->abort_on_warning ?

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx