The task is to
(a) add a comment on indexes and
(b) increase the maximum length of column, table and the new index comments.
The patch committed on behalf of Yoshinori Matsunobu (Yoshinori.Matsunobu@Sun.COM).
m_tickets.front() == m_trans_sentinel'".
Debug build of server crashed due to assert failure in MDL
subsystem when one tried to execute multi-table REPAIR or
OPTIMIZE in autocommit=0 mode.
The assert failure occured when multi-table REPAIR or OPTIMIZE
started processing of second table from its table list and
tried to acquire upgradable metadata lock on this table.
The cause of the assert failure were MDL locks left over from
processing of previous table. It turned out that in autocommit=0
mode close_thread_tables() which happens at the end of table
processing doesn't release metadata locks.
This fix solves problem by releasing locks explicitly using
MDL_context::release_trans_locks() call.
Bug #48248 assert in MDL_ticket::upgrade_shared_lock_to_exclusive
The assert would happen if REPAIR TABLE was used on a table already
locked by LOCK TABLES READ. REPAIR mistakenly tried to upgrade the
read-lock to exclusive, thereby triggering the assert.
The cause of the problem was that REPAIR TABLE ignored errors
from opening and locking tables. This is by design, as REPAIR
can be used to broken tables that cannot be opened. However,
repair also ignored logical errors such as the inability to
exclusivly lock a table due to conflicting LOCK TABLES.
This patch fixes the problem by not ignoring errors from
opening and locking tables if inside LOCK TABLES mode.
In LOCK TABLES we already know that the table can be opened,
so that the failure to open must be a logical error.
Test added to repair.test.
Engine doesn't allow me to.
In case of incompatible changes between old and new table
versions, the mysqlcheck program prints error messages like
this:
error: Table upgrade required. Please do
"REPAIR TABLE `table_name`" to fix it!
However, InnoDB doesn't support REPAIR TABLE query, so the
message is confusing.
Error message text has been changed to:
Table upgrade required. Please do "REPAIR TABLE `table_name`"
or dump/reload to fix it!"
The REPAIR TABLE ... USE_FRM query silently corrupts data of tables
with old .FRM file version.
The mysql_upgrade client program or the REPAIR TABLE query (without
the USE_FRM clause) can't prevent this trouble, because in the
common case they don't upgrade .FRM file to compatible structure.
1. Evaluation of the REPAIR TABLE ... USE_FRM query has been
modified to reject such tables with the message:
"Failed repairing incompatible .FRM file".
2. REPAIR TABLE query (without USE_FRM clause) evaluation has been
modified to upgrade .FRM files to current version.
3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified
to return error status when .FRM file has incompatible version.
4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE
FOR UPGRADE and REPAIR TABLE queries, so their behaviors have
been changed too to upgrade .FRM files with incompatible
version numbers.
myisam_sort_buffer_size.
An incorrect length of the sort buffer was used when calculating the
maximum number of keys. When myisam_sort_buffer_size is small enough,
this could result in the number of keys < number of
BUFFPEK structures which in turn led to use of uninitialized BUFFPEKs.
Fixed by correcting the buffer length calculation.
SHOW CREATE TABLE fails
Underlying table names, that merge engine fails to open were not
reported.
With this fix CHECK TABLE issued against merge table reports all
underlying table names that it fails to open. Other statements
are unaffected, that is underlying table names are not included
into error message.
This fix doesn't solve SHOW CREATE TABLE issue.
Repair table could crash a server if there is not sufficient
memory (myisam_sort_buffer_size) to operate. Affects not only
repair, but also all statements that use create index by sort:
repair by sort, parallel repair, bulk insert.
Return an error if there is not sufficient memory to store at
least one key per BUFFPEK.
Also fixed memory leak if thr_find_all_keys returns an error.
hangs on Linux
If REPAIR TABLE ... USE_FRM is issued for table that is located in different
than default database server crash could happen.
In reopen_name_locked_table take database name from table_list (user specified
or default database) instead of from thd (default database).
Affects 4.1 only.
Fixed confusing error message from the storage engine when
it fails to open underlying table. The error message is issued
when a table is _opened_ (not when it is created).
Changed my_error() to print error messages, which come from
arbitrary registered ranges of error messages. Messages can
be unregistered (and should be at end of the program).
Added registration of handler error messages.
Added a new mi_print_error() macro and a new
mi_report_error() function, which supply error
messages with a table name.
Added calls to mi_print_error() or mi_report_error()
at all places in MyISAM, where table corruption is detected.
Fixed security problem that password was temporarly reset when someone changed GRANT for a user. (Bug #3404)
Fixed problem with PROCEDURE analyse() and impossible WHERE (Bug #2238)
Don't auto-repair tables in mysqlcheck if table type doesn't support 'check' command.
Use 0x.... as strings if 'new' mode. (bug 152)
Don't report -max on windows when InnoDB is enabled. (bug 332)
Reset current_linfo; This could cause a hang when doing PURGE LOGS.
Fix for row numbers in EXPLAIN (bug 322)
Fix that USE_FRM works for all table types (bug 97)
