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@mariadb.org