MDEV-9469: 'Incorrect key file' on ALTER TABLE
InnoDB needs to rebuild table if column name is changed and
added index (or foreign key) is created based on this new
name in same alter table.
mysql.cc:
Unlike the main MYSQL structure, kill_mysql did not have MYSQL_OPT_PROTOCOL set.
Move all connection-related settings to a separate function and
use it both for the main MYSQL and for kill_mysql.
fix a few cases where a successful ALTER was not binlogged:
* on errors after the completed ALTER, binlog it, then return an error
* don't let thd->killed abort open_table() after completed
online ALTER.
Fix the doubly questional fix for MySQL Bug#17250787:
* it detected autoinc index by looking for the first index
that starts from autoinc column. never mind one column
can be part of many indexes.
* it used autoinc_field->field_index to look up into internal
innodb dictionary. But field_index accounts for virtual
columns too, while innodb dictionary ignores them.
Find the index by its name, like elsewhere in ha_innobase.
1. check that unused inline functions are removed
2. only allow compilation if they are or if the check if overridden
3. with CMAKE_GENERATOR=Makefiles, use all flags when testing
(e.g. both CMAKE_C_FLAGS and CMAKE_C_FLAGS_DEBUG if
CMAKE_BUILD_TYPE=Debug). This is because
- on Solaris with the SunPro compiler, default CMAKE_C_FLAGS_xxx
values contain -xO2 (for Release and RelWithDebInfo)
and -g (for RelWithDebInfo and Debug)
- proper inlining only works at -xO4 without -g
- so if CMAKE_C_FLAGS has -xO4, inlining would work in
configure.cmake (before this fix) and fail during actual compilation
also remove the outdated check for inline from myu_global.h
1. unused static inline functions are only removed at -xO4,
otherwise test binaries will depend on various mysys
symbols that they don't use. Link test with libmysys.
2. Sphinx - don't instantiate (explicitly) templates before
they're defined. Or, rather, don't instantiate them explicitly at
all.
3. GIS - don't use anonymous unions and structs.
from catalog functions and tables. It does now and when decimal
is NULL defines DOUBLE without parameters.
modified: storage/connect/ha_connect.cc
modified: storage/connect/mysql-test/connect/r/odbc.result
modified: storage/connect/mysql-test/connect/r/odbc_oracle.result
modified: storage/connect/mysql-test/connect/r/odbc_postgresql.result
modified: storage/connect/mysql-test/connect/r/odbc_sqlite3.result
modified: storage/connect/mysql-test/connect/r/odbc_xls.result
modified: storage/connect/odbconn.cpp
modified: storage/connect/table.cpp
modified: storage/connect/valblk.h
Limit binlog recovery so that the wsrep position found from
storage engines is not exceeded. This is required to have consistent
position between wsrep position stored in innodb header and
recoverd binlog.
- Eliminates code duplication in query cache patch
- Reduces the number of iterations in mysql-wsrep#201.test
to shorten the execution time
- Adds a new test case that exercises more scenarios
- Fixes query cache so that it is aware of wsrep_sync_wait.
Query cache would return (possibly stale) results to the
client, regardless of the value of wsrep_sync_wait.
- Includes the test case that reproduced the issue.
Problem was that created table was not marked as used (not set query_id) and so opening tables for stored function pick it up (as opened place holder for it) and used changing TABLE internals.
The select mentioned in the bug attempted to create a temporary table
using the maria storage engine. The table needs to have primary keys such that
duplicates can be removed. Unfortunately this use case has a longer
than allowed key and the tmp table got created without a temporary key.
We must not allow materialization for the subquery if the total key
length and key parts is greater than what the storage engine supports.
When one evaluates row-based comparison like (X, Y) = (A,B), one should
first call bring_value() for the Item that returns row value. If you
don't do that and just attempt to read values of X and Y, you get stale
values.
Semi-join/Materialization can take a row-based comparison apart and
make ref access from it. In that case, we need to call bring_value()
to get the index lookup components.
Consider a query with subquery in form t.key=(select ...). Suppose, the
parent query uses this equality for ref access.
It will attempt to evaluate the subquery in get_best_combination(),
right before the join->join_tab[...] array is filled. The problem was
that subquery optimization will attempt to look at parent's join->join_tab
to check how many times subquery will be executed (and crash).
Fixed by not doing that when the subquery is constant (non-constant
subqueries are only be evaluated during join execution, so they are not
affected)
