"log.cc:1448: failed assertion `mysql_bin_log.is_open() && rex_data->empty()'"
When Federated's transaction support was disabled by bug29875,
this assertion became unreproducable.
"Federated Denial of Service"
Federated storage engine used to attempt to open connections within
the ::create() and ::open() methods which are invoked while LOCK_open
mutex is being held by mysqld. As a result, no other client sessions
can open tables while Federated is attempting to open a connection.
Long DNS lookup times would stall mysqld's operation and a rogue
connection string which connects to a remote server which simply
stalls during handshake can stall mysqld for a much longer period of
time.
This patch moves the opening of the connection much later, when the
federated actually issues queries, by which time the LOCK_open mutex is
no longer being held.
Stopping mysql server could result in an entry in mysql error
file: "InnoDB: Error: MySQL is freeing a thd".
This happened because InnoDB assumes that the server will never
call external_lock(F_UNLCK) in case external_lock(READ/WRITE)
failed.
Prior to this patch we haven't had strict definition whether
external_lock(F_UNLCK) must be called in case external_lock(READ/WRITE)
fails.
This patch states that we never call external_lock(F_UNLCK) in case
external_lock(READ/WRITE) fails.
When the SQL_BIG_RESULT flag is specified SELECT should store items from the
select list in the filesort data and use them when sending to a client.
The get_addon_fields function is responsible for creating necessary structures
for that. But this function was allowed to do so only for SELECT and
INSERT .. SELECT queries. This makes the SQL_BIG_RESULT useless for
the CREATE .. SELECT queries.
Now the get_addon_fields allows storing select list items in the filesort
data for the CREATE .. SELECT queries.
"getGeneratedKeys() does not work with FEDERATED table"
mysql_insert() expected the storage engine to update the row data
during the write_row() operation with the value of the new auto-
increment field. The field must be updated when only one row has
been inserted as mysql_insert() would ignore the thd->last_insert.
This patch implements HA_STATUS_AUTO support in ha_federated::info()
and ensures that ha_federated::write_row() does update the row's
auto-increment value.
The test case was written in C as the protocol's 'id' value is
accessible through libmysqlclient and not via SQL statements.
mysql-test-run.pl was extended to enable running the test binary.
If a primary key is defined over column c of enum type then
the EXPLAIN command for a look-up query of the form
SELECT * FROM t WHERE c=0
said that the query was with an impossible where condition though the
query correctly returned non-empty result set when the table indeed
contained rows with error empty strings for column c.
This kind of misbehavior was due to a bug in the function
Field_enum::store(longlong,bool) that erroneously returned 1 if
the the value to be stored was equal to 0.
Note that the method
Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
correctly returned 0 if a value of the error empty string
was stored.
