Error was emitted when one tried to select information from view which used
merge algorithm and which also had CONVERT_TZ() function in its select list.
This bug was caused by wrong assumption that global table list for view
which is handled using merge algorithm begins from tables belonging to
the main select of this view. Nowadays the above assumption is not true only
when one uses convert_tz() function in view's select list, but in future
other cases may be added (for example we may support merging of views
with subqueries in select list one day). Relying on this false assumption
led to the usage of wrong table list for field lookups and therefor errors.
With this fix we explicitly use pointer to the beginning of main select's
table list.
Make InnoDB option "loose", as the server might be
started with this option just to find out the test
is to be skipped in the configuration (bug#17359)
Now NDB is only initialized and started when the tests that are
being run will make use of it. The same thing is also done for the
slave databases and the instance manager.
After review from Magnus: Only take a snapshot of the data directories
that are in use.
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
Fix BUG#16814: "SHOW INNODB STATUS format error in LATEST FOREIGN KEY ERROR section"
Add a missing newline to the LAST FOREIGN KEY ERROR section in SHOW INNODB STATUS
output.
Fix BUG#18934: "InnoDB crashes when table uses column names like DB_ROW_ID".
Refuse tables that use reserved column names.
Fixes for Bug#12429: Replication tests fail: "Slave_IO_Running" (?) differs related to MySQL 4.1
and Bug#16920 rpl_deadlock_innodb fails in show slave status (reported for MySQL 5.1)
After a locking error the open table(s) were not fully
cleaned up for reuse. But they were put into the open table
cache even before the lock was tried. The next statement
reused the table(s) with a wrong lock type set up. This
tricked MyISAM into believing that it don't need to update
the table statistics. Hence CHECK TABLE reported a mismatch
of record count and table size.
Fortunately nothing worse has been detected yet. The effect
of the test case was that the insert worked on a read locked
table. (!)
I added a new function that clears the lock type from all
tables that were prepared for a lock. I call this function
when a lock failes.
No test case. One test would add 50 seconds to the
test suite. Another test requires file mode modifications.
I added a test script to the bug report. It contains three
cases for failing locks. All could reproduce a table
corruption. All are fixed by this patch.
This bug was not lock timeout specific.
