Problem: setting Item_func_rollup_const::null_value property to argument's null_value
before (without) the argument evaluation may result in a crash due to wrong null_value.
Fix: use is_null() to set Item_func_rollup_const::null_value instead as it evaluates
the argument if necessary and returns a proper value.
Bug#31567 "datadict" tests (all engines) fail:
Reference protocol is non-standard build
Bug#30418 "datadict" tests (all engines) fail:
Dependency on the host name for ordering
Modifications:
1. The standard builds (build team) do not contain
the collation 'utf8_general_cs'.
The common developer builds (compuile-....-max)
contain this collation.
Solution fitting to both build variants:
Exclude the collation 'utf8_general_cs' from
result sets.
2. Use mysqltest builtin sorting of result set for
the statement where the hostname affects the
row order.
Problem: even if an Item_xml_str_func successor returns NULL, it doesn't have
a corresponding property (maybe_null) set, that leads to a failed assertion.
Fix: set nullability property of Item_xml_str_func.
Problem: we have CHECK TABLE options allowed (by accident?) for
ANALYZE/OPTIMIZE TABLE.
Fix: disable them.
Note: it might require additional fixes in 5.1/6.0
Problem: caching 00000000-00000099 dates as integer values we're
improperly shifting them up twice in the get_datetime_value().
Fix: don't shift cached DATETIME values up for the second time.
In several cases, an error when processing the query would cause mysql to
return to the top level without printing warnings. Fix is to always
print any available warnings before returning to the top level.
The problem is that DROP TABLE and other DDL statements failed to
automatically close handlers associated with tables that were marked
for reopen (FLUSH TABLES).
The current implementation fails to properly discard handlers of
dropped tables (that were marked for reopen) because it searches
on the open handler tables list and using the current alias of the
table being dropped. The problem is that it must not use the open
handler tables list to search because the table might have been
closed (marked for reopen) by a flush tables command and also it
must not use the current table alias at all since multiple different
aliases may be associated with a single table. This is specially
visible when a user has two open handlers (using alias) of a same
table and a flush tables command is issued before the table is
dropped (see test case). Scanning the handler table list is also
useless for dropping handlers associated with temporary tables,
because temporary tables are not kept in the THD::handler_tables
list.
The solution is to simple scan the handlers hash table searching
for, and deleting all handlers with matching table names if the
reopen flag is not passed to the flush function, indicating that
the handlers should be deleted. All matching handlers are deleted
even if the associated the table is not open.
Bug#31610 Remove outdated and redundant tests:
partition_02myisam partition_03ndb
Bug#32405 testsuite parts: partition_char_myisam wrong content
and cleanup of testsuite
- remove/correct wrong comments
- remove workarounds for fixed bugs
- replace error numbers with error names
- exclude subtests from execution which fail now because of
new limitations for partitioning functions
- remove code for the no more intended dual use
fast test in regression tests/slow test in testsuite
- analyze and fix problems with partition_char_innodb
- fix problems caused by last change of error numbers
- Introduce error name to error number mapping which makes
maintenance after next error renumbering easier
Problem was for LINEAR HASH/KEY. Crashes because of wrong partition id
returned when creating the new altered partitions. (because of wrong
linear hash mask)
Solution: Update the linear hash mask before using it for the new
altered table.
Server failed in assert() when we tried to create a DECIMAL() temp field
with a scale of more than the allowed 30. Now we limit the scale to the
allowed maximum. A truncation warning is thrown as necessary.
Problem: there's no guarantee that the user variable item's result_field
is assigned when we're adjusting its table read map.
Fix: check the result_field before using it.
DROP DATABASE statement writes changes to mysql.proc table under RBR
When replicating a DROP DATABASE statement with a database holding
stored procedures, the changes to the mysql.proc table was recorded
in the binary log under row-based replication.
With this patch, the thread uses statement-logging format for the
duration of the DROP DATABASE statement. The logging format is
(already) reset at the end of the statement, so no additional code
for resetting the logging format is necessary.
corrupts a MERGE table
Bug 26867 - LOCK TABLES + REPAIR + merge table result in
memory/cpu hogging
Bug 26377 - Deadlock with MERGE and FLUSH TABLE
Bug 25038 - Waiting TRUNCATE
Bug 25700 - merge base tables get corrupted by
optimize/analyze/repair table
Bug 30275 - Merge tables: flush tables or unlock tables
causes server to crash
Bug 19627 - temporary merge table locking
Bug 27660 - Falcon: merge table possible
Bug 30273 - merge tables: Can't lock file (errno: 155)
The problems were:
Bug 26379 - Combination of FLUSH TABLE and REPAIR TABLE
corrupts a MERGE table
1. A thread trying to lock a MERGE table performs busy waiting while
REPAIR TABLE or a similar table administration task is ongoing on
one or more of its MyISAM tables.
2. A thread trying to lock a MERGE table performs busy waiting until all
threads that did REPAIR TABLE or similar table administration tasks
on one or more of its MyISAM tables in LOCK TABLES segments do UNLOCK
TABLES. The difference against problem #1 is that the busy waiting
takes place *after* the administration task. It is terminated by
UNLOCK TABLES only.
3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate the
lock. This does *not* require a MERGE table. The first FLUSH TABLES
can be replaced by any statement that requires other threads to
reopen the table. In 5.0 and 5.1 a single FLUSH TABLES can provoke
the problem.
Bug 26867 - LOCK TABLES + REPAIR + merge table result in
memory/cpu hogging
Trying DML on a MERGE table, which has a child locked and
repaired by another thread, made an infinite loop in the server.
Bug 26377 - Deadlock with MERGE and FLUSH TABLE
Locking a MERGE table and its children in parent-child order
and flushing the child deadlocked the server.
Bug 25038 - Waiting TRUNCATE
Truncating a MERGE child, while the MERGE table was in use,
let the truncate fail instead of waiting for the table to
become free.
Bug 25700 - merge base tables get corrupted by
optimize/analyze/repair table
Repairing a child of an open MERGE table corrupted the child.
It was necessary to FLUSH the child first.
Bug 30275 - Merge tables: flush tables or unlock tables
causes server to crash
Flushing and optimizing locked MERGE children crashed the server.
Bug 19627 - temporary merge table locking
Use of a temporary MERGE table with non-temporary children
could corrupt the children.
Temporary tables are never locked. So we do now prohibit
non-temporary chidlren of a temporary MERGE table.
Bug 27660 - Falcon: merge table possible
It was possible to create a MERGE table with non-MyISAM children.
Bug 30273 - merge tables: Can't lock file (errno: 155)
This was a Windows-only bug. Table administration statements
sometimes failed with "Can't lock file (errno: 155)".
These bugs are fixed by a new implementation of MERGE table open.
When opening a MERGE table in open_tables() we do now add the
child tables to the list of tables to be opened by open_tables()
(the "query_list"). The children are not opened in the handler at
this stage.
After opening the parent, open_tables() opens each child from the
now extended query_list. When the last child is opened, we remove
the children from the query_list again and attach the children to
the parent. This behaves similar to the old open. However it does
not open the MyISAM tables directly, but grabs them from the already
open children.
When closing a MERGE table in close_thread_table() we detach the
children only. Closing of the children is done implicitly because
they are in thd->open_tables.
For more detail see the comment at the top of ha_myisammrg.cc.
Changed from open_ltable() to open_and_lock_tables() in all places
that can be relevant for MERGE tables. The latter can handle tables
added to the list on the fly. When open_ltable() was used in a loop
over a list of tables, the list must be temporarily terminated
after every table for open_and_lock_tables().
table_list->required_type is set to FRMTYPE_TABLE to avoid open of
special tables. Handling of derived tables is suppressed.
These details are handled by the new function
open_n_lock_single_table(), which has nearly the same signature as
open_ltable() and can replace it in most cases.
In reopen_tables() some of the tables open by a thread can be
closed and reopened. When a MERGE child is affected, the parent
must be closed and reopened too. Closing of the parent is forced
before the first child is closed. Reopen happens in the order of
thd->open_tables. MERGE parents do not attach their children
automatically at open. This is done after all tables are reopened.
So all children are open when attaching them.
Special lock handling like mysql_lock_abort() or mysql_lock_remove()
needs to be suppressed for MERGE children or forwarded to the parent.
This depends on the situation. In loops over all open tables one
suppresses child lock handling. When a single table is touched,
forwarding is done.
Behavioral changes:
===================
This patch changes the behavior of temporary MERGE tables.
Temporary MERGE must have temporary children.
The old behavior was wrong. A temporary table is not locked. Hence
even non-temporary children were not locked. See
Bug 19627 - temporary merge table locking.
You cannot change the union list of a non-temporary MERGE table
when LOCK TABLES is in effect. The following does *not* work:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
ALTER TABLE m1 ... UNION=(t1,t2) ...;
However, you can do this with a temporary MERGE table.
You cannot create a MERGE table with CREATE ... SELECT, neither
as a temporary MERGE table, nor as a non-temporary MERGE table.
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
Gives error message: table is not BASE TABLE.
different error code depending on platform.
On Mac OS X, KILL statement issued to kill the current
connection would return a different error code and message than on
other platforms ('MySQL server has gone away' instead of 'Shutdown
in progress').
The reason for this difference was that on Mac OS X we have macro
SIGNAL_WITH_VIO_CLOSE defined. This macro forces KILL
implementation to close the communication socket of the thread
that is being killed. SIGNAL_WITH_VIO_CLOSE macro is defined on
platforms where just sending a signal is not a reliable mechanism
to interrupt the thread from sleeping on a blocking system call.
In a nutshell, closing the socket is a hack to work around an
operating system bug and awake the blocked thread no matter what.
However, if the thread that is being killed is the same
thread that issued KILL statement, closing the socket leads to a
prematurely lost connection. At the same time it is not necessary
to close the socket in this case, since the thread in question
is not inside a blocking system call.
The fix, therefore, is to not close the socket if the thread that
is being killed is the same that issued KILL statement, even with
defined SIGNAL_WITH_VIO_CLOSE.
