For queries of the form:
insert into cache1 select * from cache1;
We had a crash in the second call to get_status_and_flush_cache
due to cache->table being 0. This happened because for one of the
two ha_mcs_cache instances involved in this query, the call to
ha_mcs_cache::open was not setting cache_handler->file->lock.status_param.
The assignment to status_param was earlier protected by an if condition.
Solution is to remove that if condition in ha_mcs_cache::open.
For certain queries, such as:
update cs1 set i = 41 where i = 42 or (i is null and 42 is null);
the SELECT_LEX.where does not contain the required where conditions.
Server sends the where conditions in the call to cond_push(), so
we are storing them in a handler data member, condStack, and later
push them down to getSelectPlan() for UPDATES/DELETEs.
Several changes have happened in MariaDB 10.5, most notably:
* Information Schema table definitions have changed
* More things use LEX_CSTRING
This fixes all the compile issues
We were auto-assigned a DB type which could cause issues during major
upgrades. Setting to autoassign gives us a DB type of 0 which solves
these issues.
