More DBUG_PRINT (to simplify future debugging)
Aria: Added STATE_IN_REPAIR, which is set on start of repair. This allows us to see if 'crashed' flag was set intentionally.
Aria: Some trivial speedup optimization
Aria: Better warning if table was marked crashed by unfinnished repair
mysql-test/lib/v1/mysql-test-run.pl:
Fix so one can run RQG
mysql-test/suite/maria/r/maria-recovery2.result:
Update for new error message.
mysys/stacktrace.c:
Fixed compiler warning
storage/maria/ha_maria.cc:
More DBUG_PRINT
Added STATE_IN_REPAIR flag, which is set on start of repair. This allows us to see if 'crashed' flag was set intentionally.
Don't log query for dropping temporary table.
storage/maria/ha_maria.h:
Added prototype for drop_table()
storage/maria/ma_blockrec.c:
More DBUG_PRINT
Make read_long_data() inline for most cases. (Trivial speedup optimization)
storage/maria/ma_check.c:
Better warning if table was marked crashed by unfinnished repair
storage/maria/ma_open.c:
More DBUG_PRINT
storage/maria/ma_recovery.c:
Give warning if found crashed table.
Changed warning for tables that can't be opened.
storage/maria/ma_recovery_util.c:
Write warnings to DBUG file
storage/maria/maria_chk.c:
Added STATE_IN_REPAIR flag, which is set on start of repair. This allows us to see if 'crashed' flag was set intentionally.
storage/maria/maria_def.h:
Added maria_mark_in_repair(x)
storage/maria/maria_read_log.c:
Added option: --character-sets-dir
storage/maria/trnman.c:
By default set min_read_from to max value.
This allows us to remove TRN:s from rows during recovery to get more space.
This fixes bug LP#602604: RQG: ma_blockrec.c:6187: _ma_apply_redo_insert_row_head_or_tail: Assertion `0' failed on Maria engine recovery
mysql-test/suite/federated/federated_server.result:
Update to new error message
mysql-test/suite/federated/federated_server.test:
Update to new error message
storage/federatedx/ha_federatedx.cc:
Return real error code, not 0, as in some cases before.
Fixed bug: LP#603026 RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE of a Maria table
client/mysql.cc:
Removed Oracle copyright from stdout, as Oracle doesn't have copyright to all code in this file.
Ignore --comments at start of command line. This allows one to more easily run mysqltest tests trough the command line.
mysql-test/suite/maria/r/optimize.result:
Added test for LP#603026
mysql-test/suite/maria/t/optimize.test:
Added test for LP#603026
sql/net_serv.cc:
Removed DBUG_ASSERT(), as this code can happen during testing.
storage/maria/ma_check.c:
Fixed bug: LP#603026 RQG: pagecache_read: Assertion `pageno < ((1ULL) << 40)' on OPTIMIZE TABLE of a Maria table
The problem was duplicated memory usage with long packed keys.
Merge up to sunny.bains@oracle.com-20100625081841-ppulnkjk1qlazh82 .
There are 8 more changesets in mysql-5.1-innodb, but PB2 shows a
failure for a test added in one of them. If that is resolved quickly
then those 8 more changesets will be merged too.
POSIX requires that a signal handler defined with sigaction()
is not reset on delivering a signal unless SA_NODEFER or
SA_RESETHAND is set. It is therefore unnecessary to redefine
the handler on signal delivery on platforms where sigaction()
is used without those flags.
include/my_alarm.h:
Renamed DONT_REMEMBER_SIGNAL ->
SIGNAL_HANDLER_RESET_ON_DELIVERY.
include/my_global.h:
Renamed DONT_REMEMBER_SIGNAL ->
SIGNAL_HANDLER_RESET_ON_DELIVERY. The latter is now defined
only on non-BSD platforms missing the POSIX sigaction()
function.
libmysql/libmysql.c:
Renamed DONT_REMEMBER_SIGNAL ->
SIGNAL_HANDLER_RESET_ON_DELIVERY
mysys/thr_alarm.c:
Renamed DONT_REMEMBER_SIGNAL ->
SIGNAL_HANDLER_RESET_ON_DELIVERY
sql/mysqld.cc:
Renamed DONT_REMEMBER_SIGNAL ->
SIGNAL_HANDLER_RESET_ON_DELIVERY
The problem is that QUICK_SELECT_DESC behaviour depends
on used_key_parts value which can be bigger than selected
best_key_parts value if an engine supports clustered key.
But used_key_parts is overwritten with best_key_parts
value that prevents from correct selection of index
access method. The fix is to preserve used_key_parts
value for further use in QUICK_SELECT_DESC.
mysql-test/r/innodb_mysql.result:
test case
mysql-test/t/innodb_mysql.test:
test case
sql/sql_select.cc:
preserve used_key_parts value for further use in QUICK_SELECT_DESC
automatic reconnect
A client with automatic reconnect enabled will see the error
message "Lost connection to MySQL server during query" if the
connection is lost between mysql_stmt_prepare() and
mysql_stmt_execute(). The mysql_stmt_errno() number, however,
is 0 -- not the corresponding value 2013.
This patch checks for the case where the prepared statement
has been pruned due to a connection loss (i.e., stmt->mysql
has been set to NULL) during a call to cli_advanced_command(),
and avoids changing the last_errno to the result of the last
reconnect attempt.
The default value of the myisam_max_extra_sort_file_size could be
higher than the maximum accepted value, leading to warnings upon
the server start.
The solution is to simply set the value to the maximum value in a
32-bit built (2147483647, one less than the current). This should
be harmless as the option is currently unused in 5.1.
include/myisam.h:
Remove now-unused macro.
sql/mysqld.cc:
Set max value to INT_MAX32.
The problem was that a user could supply supply data in chunks
via the COM_STMT_SEND_LONG_DATA command to prepared statement
parameter other than of type TEXT or BLOB. This posed a problem
since other parameter types aren't setup to handle long data,
which would lead to a crash when attempting to use the supplied
data.
Given that long data can be supplied at any stage of a prepared
statement, coupled with the fact that the type of a parameter
marker might change between consecutive executions, the solution
is to validate at execution time each parameter marker for which
a data stream was provided. If the parameter type is not TEXT or
BLOB (that is, if the type is not able to handle a data stream),
a error is returned.
sql/sql_prepare.cc:
Before converting the parameter data stream, check the type
compatibility.
tests/mysql_client_test.c:
Add test case.
DROP USER
RENAME USER CURRENT_USER() ...
GRANT ... TO CURRENT_USER()
REVOKE ... FROM CURRENT_USER()
ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged
as 'CURRENT_USER()', it is not expanded to the real user name. When slave
executes the log event, 'CURRENT_USER()' is expand to the user of slave
SQL thread, but SQL thread's user name always NULL. This breaks the replication.
After this patch, session's user will be written into query log events
if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.
mysql-test/include/diff_tables.inc:
Expend its abilities.
Now it can diff not only in sessions of 'master' and 'slave', but
other sessions as well.
mysql-test/include/rpl_diff_tables.inc:
Diff the same table between master and slaves.
sql/log_event.cc:
session's user will be written into Query_log_event, if is_current_user_used() is TRUE.
On slave SQL thread, Only thd->variables.current_user is written into Query_log_event,
if it exists.
sql/sql_acl.cc:
On slave SQL thread, grantor should copy from thd->variables.current_user, if it exists
sql/sql_class.h:
On slave SQL thread, thd->variables.current_user is used to store the applying event's
invoker.
This deadlock happened if DROP DATABASE was blocked due to an open
HANDLER table from a different connection. While DROP DATABASE
is blocked, it holds the LOCK_mysql_create_db mutex. This results
in a deadlock if the connection with the open HANDLER table tries
to execute a CREATE/ALTER/DROP DATABASE statement as they all
try to acquire LOCK_mysql_create_db.
This patch makes this deadlock scenario very unlikely by closing and
marking for re-open all HANDLER tables for which there are pending
conflicing locks, before LOCK_mysql_create_db is acquired.
However, there is still a very slight possibility that a connection
could access one of these HANDLER tables between closing/marking for
re-open and the acquisition of LOCK_mysql_create_db.
This patch is for 5.1 only, a separate and complete fix will be
made for 5.5+.
Test case added to schema.test.
and clarifies the invariant in dict_table_get_on_id().
In Mar 2007 Marko observed a crash during recovery, the crash resulted from
an UNDO operation on a system table. His solution was to acquire an X lock on
the data dictionary, this in hindsight was an overkill. It is unclear what
caused the crash, current hypothesis is that it was a memory corruption.
The X lock results in performance issues by when undoing changes due to
rollback during normal operation on regular tables.
Why the change is safe:
======================
The InnoDB code has changed since the original X lock change was made. In the
new code we always lock the data dictionary in X mode during startup when
UNDOing operations on the system tables (this is a given). This ensures that
the crash Marko observed cannot happen as long as all transactions that update
the system tables follow the standard rules by setting the appropriate DICT_OP
flag when writing the log records when they make the changes.
If transactions violate the above mentioned rule then during recovery (at
startup) the rollback code (see trx0roll.c) will not acquire the X lock
and we will see the crash again. This will however be a different bug.
