localhost/default port
When creating federated table that points to unspecified host or
localhost on unspecified port or port is 0, small memory leak occurs.
This happens because we make a copy of unix socket path, which is
never freed.
With this fix we do not make a copy of unix socket path, instead
share->socket points to MYSQL_UNIX_ADDR constant directly.
This fix is covered by a test case for BUG34788.
Affects 5.0 only.
correctly - crashes server !
Creating federated table with connect string containing empty
(zero-length) host name and port is evaluated as 0 (port is
incorrect, omitted or 0) crashes server.
This happens because federated calls strcmp() with NULL pointer.
Fixed by avoiding strcmp() call if hostname is set to NULL.
from storage engine
Federated may crash a server, return wrong result set, return
"ERROR 1030 (HY000): Got error 1430 from storage engine" message
when local (engine=federated) table has a key against nullable
column.
The problem was wrong implementation of function that creates
WHERE clause for remote query from key.
filesort() uses file->estimate_rows_upper_bound() call to allocate
internal buffers. If this function returns a value smaller than
a number of row that will be returned later in find_all_keys(),
that can cause server crash.
Fixed by implementing ha_federated::estimate_rows_upper_bound() to
return maximum possible number of rows.
Present estimation for FEDERATED always returns 0 if the linked to the VIEW.
if remote server sends malicious response.
We need to check if the SHOW TABLE STATUS query we issue inside the
FEDERATED engine returned the result with the proper (or just sufficient)
number of rows. Otherwise statements like row[12] can crash the server.
"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.
"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.
"Federared Transactions Failure"
Bug occurs when the user performs an operation which inserts more than
one row into the federated table and the federated table references a
remote table stored within a transactional storage engine. When the
insert operation for any one row in the statement fails due to
constraint violation, the federated engine is unable to perform
statement rollback and so the remote table contains a partial commit.
The user would expect a statement to perform the same so a statement
rollback is expected.
This bug was fixed by implementing bulk-insert handling into the
federated storage engine. This will relieve the bug for most common
situations by enabling the generation of a multi-row insert into the
remote table and thus permitting the remote table to perform
statement rollback when neccessary.
The multi-row insert is limited to the maximum packet size between
servers and should the size overflow, more than one insert statement
will be sent and this bug will reappear. Multi-row insert is disabled
when an "INSERT...ON DUPLICATE KEY UPDATE" is being performed.
The bulk-insert handling will offer a significant performance boost
when inserting a large number of small rows.
This patch builds on Bug29019 and Bug25511
"Federated INSERT failures"
Federated does not correctly handle "INSERT...ON DUPLICATE KEY UPDATE"
However, implementing such support is not reasonably possible without
increasing complexity of the storage engine: checking that constraints
on remote server match local server and parsing error messages.
This patch causes 'ON DUPLICATE KEY' to fail with ER_DUP_KEY message
if a conflict occurs and not to fail silently.
"REPLACE/INSERT IGNORE/UPDATE IGNORE doesn't work"
Federated does not record neccessary HA_EXTRA flags in order to
support REPLACE/INSERT IGNORE/UPDATE IGNORE.
Implement ::extra() to capture flags neccessary for functionality.
New function append_ident() to better escape identifiers consistantly.
- Removed not used variables and functions
- Added #ifdef around code that is not used
- Renamed variables and functions to avoid conflicts
- Removed some not used arguments
Fixed some class/struct warnings in ndb
Added define IS_LONGDATA() to simplify code in libmysql.c
I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
Fixed compiler warnings (detected by VC++):
- Removed not used variables
- Added casts
- Fixed wrong assignments to bool
- Fixed wrong calls with bool arguments
- Added missing argument to store(longlong), which caused wrong store method to be called.
(Mostly in DBUG_PRINT() and unused arguments)
Fixed bug in query cache when used with traceing (--with-debug)
Fixed memory leak in mysqldump
Removed warnings from mysqltest scripts (replaced -- with #)
- Added 'SET NAMES <charset>" upon ::open
- Added test and results for simple UTF test
federated.test:
BUG #17044 Federated Storage Engine not UTF8 clean
New test. Using hex - pasting various charsets in the terminal doesn't work.
federated.result:
BUG# 17044 Federated Storage Engine not UTF8 clean
New test results
ha_federated.cc:
BUG# 17044 Federated Storage Engine not UTF8 clean
Upon ::open, set names to table's charset
The Federated storage engine used Field methods that had arbitrary limits on
the amount of data they could process, which caused problems with data
over that limit (4K). By removing those Field methods and just using
features of the String class, we can avoid this problem.
When building the UPDATE query to send to the remote server, the
federated storage engine built the query incorrectly if it was updating
a field to be NULL.
Thanks to Bjrn Steinbrink for an initial patch for the problem.
- Fixed tests
- Optimized new code
- Fixed some unlikely core dumps
- Better bug fixes for:
- #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
- #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
Bad examples of usage of a string with its length fixed.
The incorrect length in the trigger file configuration descriptor
fixed (BUG#14090).
A hook for unknown keys added to the parser to support old .TRG files.
