from next-mr-bugfixing:
BUG#54682 "set sql_select_limit=0 does not work"; let SQL_SELECT_LIMIT=0
work like it does in 5.1.
mysql-test/suite/sys_vars/r/sql_select_limit_func.result:
before the fix, the SET would emit a warning (0 being rounded up to 1)
and SELECTs would return one row.
sql/sys_vars.cc:
0 is allowed, it means an implicit LIMIT 0 (i.e. no rows returned)
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.
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->invoker is written into Query_log_event,
if it exists.
sql/sql_acl.cc:
On slave SQL thread, grantor should copy from thd->invoker, if it exists
sql/sql_class.h:
On slave SQL thread, thd->invoker is used to store the applying event's
invoker.
BUG#54872 MBR: replication failure caused by using tmp table inside transaction
Changed criteria to classify a statement as unsafe in order to reduce the
number of spurious warnings. So a statement is classified as unsafe when
there is on-going transaction at any point of the execution if:
1. The mixed statement is about to update a transactional table and
a non-transactional table.
2. The mixed statement is about to update a temporary transactional
table and a non-transactional table.
3. The mixed statement is about to update a transactional table and
read from a non-transactional table.
4. The mixed statement is about to update a temporary transactional
table and read from a non-transactional table.
5. The mixed statement is about to update a non-transactional table
and read from a transactional table when the isolation level is
lower than repeatable read.
After updating a transactional table if:
6. The mixed statement is about to update a non-transactional table
and read from a temporary transactional table.
7. The mixed statement is about to update a non-transactional table
and read from a temporary transactional table.
8. The mixed statement is about to update a non-transactionala table
and read from a temporary non-transactional table.
9. The mixed statement is about to update a temporary non-transactional
table and update a non-transactional table.
10. The mixed statement is about to update a temporary non-transactional
table and read from a non-transactional table.
11. A statement is about to update a non-transactional table and the
option variables.binlog_direct_non_trans_update is OFF.
The reason for this is that locks acquired may not protected a concurrent
transaction of interfering in the current execution and by consequence in
the result. So the patch reduced the number of spurious unsafe warnings.
Besides we fixed a regression caused by BUG#51894, which makes temporary
tables to go into the trx-cache if there is an on-going transaction. In
MIXED mode, the patch for BUG#51894 ignores that the trx-cache may have
updates to temporary non-transactional tables that must be written to the
binary log while rolling back the transaction.
So we fix this problem by writing the content of the trx-cache to the
binary log while rolling back a transaction if a non-transactional
temporary table was updated and the binary logging format is MIXED.
switching binlog format to ROW
BUG 52616 fixed the case which the user would switch from STMT to
ROW binlog format, but the server would silently ignore it. After
that fix thd->is_current_stmt_binlog_format_row() reports correct
value at logging time and events are logged in ROW (as expected)
instead of STMT as they were previously and wrongly logged.
However, the fix was only partially complete, because on
disconnect, at THD cleanup, the implicit logging of temporary
tables is conditionally performed. If the binlog_format==ROW and
thd->is_current_stmt_binlog_format_row() is true then DROPs are
not logged. Given that the user can switch from STMT to ROW, this
is wrong because the server cannot tell, just by relying on the
ROW binlog format, that the tables have been dropped before. This
is effectively similar to the MIXED scenario when a switch from
STMT to ROW is triggered.
We fix this by removing this condition from
close_temporary_tables.
mysql-test/extra/binlog_tests/drop_temp_table.test:
Added binlog test case.
mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result:
Result changes because:
- there is a missing drop on three temporary tables
- it now contains results for the test added
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
Result now contains the implicit drop for the temporary table.
mysql-test/suite/binlog/r/binlog_stm_drop_tmp_tbl.result:
Result file changed because it now contains results for added
test case.
mysql-test/suite/rpl/r/rpl_drop_temp.result:
Result file changed because it now contains results for added
test case.
mysql-test/suite/rpl/t/rpl_drop_temp.test:
Added replication test case.
sql/sql_base.cc:
Removed the condition that would make the server to skip
logging implicit drops when ROW binary log format mode was
in use.
Additionally, deployed DBUG_ENTER/RETURN macros.
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.
DML flow and SAVEPOINT
The problem was that replication could break if a transaction involving
both transactional and non-transactional tables was rolled back to a
savepoint. It broke if a concurrent connection tried to drop a
transactional table which was locked after the savepoint was set.
This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed as the
lock on the table was dropped by the transaction. When the slave later
tried to apply the binlog, it would fail as the table would already
have been dropped.
The reason for the problem is that transactions involving both
transactional and non-transactional tables are written fully to the
binlog during ROLLBACK TO SAVEPOINT. At the same time, metadata locks
acquired after a savepoint, were released during ROLLBACK TO SAVEPOINT.
This allowed a second connection to drop a table only used between
SAVEPOINT and ROLLBACK TO SAVEPOINT. Which caused the transaction binlog
to refer to a non-existing table when it was written during ROLLBACK
TO SAVEPOINT.
This patch fixes the problem by not releasing metadata locks when
ROLLBACK TO SAVEPOINT is executed if binlogging is enabled.
mysql-test/suite/perfschema/t/no_threads-master.opt:
Innodb will start multiple threads, which is
not compatible with --one-thread. Disable
innodb to be able to run the test case.
mysql_client_binlog_statement
Problem: server may read from unassigned memory performing
"wrong" BINLOG queries.
Fix: never read from unassigned memory.
mysql-test/suite/binlog/r/binlog_base64_flag.result:
Fix for bug #54393: crash and/or valgrind errors in
mysql_client_binlog_statement
- test result.
mysql-test/suite/binlog/t/binlog_base64_flag.test:
Fix for bug #54393: crash and/or valgrind errors in
mysql_client_binlog_statement
- test case.
sql/sql_binlog.cc:
Fix for bug #54393: crash and/or valgrind errors in
mysql_client_binlog_statement
- coded_len should not count trailing '/0';
- never read from unassigned memory.
The default storage engine is changed from MyISAM to
InnoDB, in all builds except for the embedded server.
In addition, the following system variables are
changed:
* innodb_file_per_table is enabled
* innodb_strict_mode is enabled
* innodb_file_format_name_update is changed
to 'Barracuda'
The test suite is changed so that tests that do not
explicitly include the have_innodb.inc are run with
--default-storage-engine=MyISAM. This is to ease the
transition, so that most regression tests are run
with the same engine as before.
Some tests are disabled for the embedded server
regression test, as the output of certain statements
will be different that for the regular server
(i.e SELECT @@default_storage_engine). This is to
ease transition.
mysql-test/mysql-test-run.pl:
The regression test suite now adds a
--default-storage-engine=MyISAM for all non-innodb
tests. This behaviour can be controlled by the
default-myisam switch in mysql-test-run
mysql-test/t/bootstrap-master.opt:
The bootstrap test can only be run without InnoDB
as it starts several mysqld instances on the same
datadir. This is possible with MyISAM, but not
with InnoDB.
storage/innobase/CMakeLists.txt:
Build InnoDB per default
storage/innobase/handler/ha_innodb.cc:
Change default values for system variables
Enable file_per_table
Enable strict_mode
Upgrade default file format to Barracuda
and innodb_file_format_max two system variables. And this also fixes
bug #53654 after 2nd shutdown innodb_file_format_check attains strange
values.
rb://366 approved by Marko
Let mtr lookup the plugins, rather than hard-coding autotools lib path.
mysql-test/include/not_parallel.inc:
Add new feature for skipping when running in parallel.
mysql-test/mysql-test-run.pl:
Use find_plugin to locate plugins.
Export opt_parallel in environment.
mysql-test/suite/federated/federated_plugin-master.opt:
Use plugin dir from mtr.
mysql-test/suite/federated/federated_plugin.test:
Skip test, disabled.
mysql-test/t/archive_plugin-master.opt:
Use plugin dir from mtr.
mysql-test/t/archive_plugin.test:
Skip test if running in parallel.
mysql-test/t/blackhole_plugin-master.opt:
Use plugin dir from mtr.
mysql-test/t/blackhole_plugin.test:
Skip test if running in parallel.
------------------------------------------------------------
revno: 3506
revision-id: sergey.glukhov@sun.com-20100609121718-04mpk5kjxvnrxdu8
parent: sergey.glukhov@sun.com-20100609120734-ndy2281wau9067zv
committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
branch nick: mysql-5.1-innodb
timestamp: Wed 2010-06-09 16:17:18 +0400
message:
Bug#38999 valgrind warnings for update statement in function compare_record()
(InnoDB plugin branch)
@ mysql-test/suite/innodb_plugin/r/innodb_mysql.result
test case
@ mysql-test/suite/innodb_plugin/t/innodb_mysql.test
test case
@ storage/innodb_plugin/row/row0sel.c
init null bytes with default values as they might be
left uninitialized in some cases and these uninited bytes
might be copied into mysql record buffer that leads to
valgrind warnings on next use of the buffer.
mysql-test/suite/innodb/r/innodb_information_schema.result:
The transaction is in REPEATABLE READ, since the
iso level was changed to SERIALIZABLE only for the
previous trx.
mysql-test/suite/innodb/t/innodb-semi-consistent.test:
'commit' was missing from the original patch
mysql-test/t/parser.test:
Moved the test for Bug#46527 to parser_not_embedded,
since "disconnect default" isn't allowed with
the embedded server.
mysql-test/t/parser_not_embedded.test:
Moved the test for Bug#46527 to parser_not_embedded,
since "disconnect default" isn't allowed with
the embedded server.
Bug#46527 COMMIT AND CHAIN RELEASE does not make sense
Bug#53343 completion_type=1, COMMIT/ROLLBACK AND CHAIN don't
preserve the isolation level
Bug#53346 completion_type has strange effect in a stored
procedure/prepared statement
Added test cases to verify the expected behaviour of :
SET SESSION TRANSACTION ISOLATION LEVEL,
SET TRANSACTION ISOLATION LEVEL,
@@completion_type,
COMMIT AND CHAIN,
ROLLBACK AND CHAIN
..and some combinations of the above
Logging slow stored procedures caused the slow log to write
very large lock times. The lock times was a result of a
negative number being cast to an unsigned integer.
The reason the lock time appeard negative was because
one of the measurements points was reset after execution
causing it to change order with the start time of the
statement.
This bug is related to bug 47905 which in turn was
introduced because of a joint fix for 12480,12481,12482 and 11587.
The fix is to only reset the start_time before any statement
execution in a SP while not resetting start_utime or
utime_after_lock which are used for measuring the
performance of the SP. Start_time is used to set the
timestamp on the replication event which controlls how
the slave interprets time functions like NOW().
locks for DML statements and changes the way MDL locks
are acquired/granted in contended case.
Instead of backing-off when a lock conflict is encountered
and waiting for it to go away before restarting open_tables()
process we now wait for lock to be released without releasing
any previously acquired locks. If conflicting lock goes away
we resume opening tables. If waiting leads to a deadlock we
try to resolve it by backing-off and restarting open_tables()
immediately.
As result both waiting for possibility to acquire and
acquiring of a metadata lock now always happen within the
same MDL API call. This has allowed to make release of a lock
and granting it to the most appropriate pending request an
atomic operation.
Thanks to this it became possible to wake up during release
of lock only those waiters which requests can be satisfied
at the moment as well as wake up only one waiter in case
when granting its request would prevent all other requests
from being satisfied. This solves thundering herd problem
which occured in cases when we were releasing some lock and
woke up many waiters for SNRW or X locks (this was the issue
in bug#52289 "performance regression for MyISAM in sysbench
OLTP_RW test".
This also allowed to implement more fair (FIFO) scheduling
among waiters with the same priority.
It also opens the door for introducing new types of requests
for metadata locks such as low-prio SNRW lock which is
necessary in order to support LOCK TABLES LOW_PRIORITY WRITE.
Notice that after this sometimes can report ER_LOCK_DEADLOCK
error in cases in which it has not happened before.
Particularly we will always report this error if waiting for
conflicting lock has happened in the middle of transaction
and resulted in a deadlock. Before this patch the error was
not reported if deadlock could have been resolved by backing
off all metadata locks acquired by the current statement.
mysql-test/r/mdl_sync.result:
Added test coverage for some aspects of deadlock handling in
metadata locking subsystem.
Adjusted test case after removing back-off in general case
when conflicting metadata lock is encountered during
open_tables() (now this happens only if waiting for
conflicting lock to go away leads to a deadlock).
mysql-test/r/sp_sync.result:
Adjusted test case after removing back-off in general case
when conflicting metadata lock is encountered during
open_tables() (now this happens only if waiting for
conflicting lock to go away leads to a deadlock).
mysql-test/suite/perfschema/r/dml_setup_instruments.result:
Adjusted test results after renaming MDL_context::
m_waiting_for_lock rwlock to m_LOCK_waiting_for.
mysql-test/suite/rpl/r/rpl_sp.result:
Adjusted test case after implementing new approach to
acquiring metadata locks in open_tables(). We no longer
release all MDL locks acquired by statement before waiting
for conflicting lock to go away. As result DROP FUNCTION
statement has to wait for DML statement which managed to
acquire metadata lock on function being dropped and now
waits for other conflicting metadata lock to go away.
mysql-test/suite/rpl/t/rpl_sp.test:
Adjusted test case after implementing new approach to
acquiring metadata locks in open_tables(). We no longer
release all MDL locks acquired by statement before waiting
for conflicting lock to go away. As result DROP FUNCTION
statement has to wait for DML statement which managed to
acquire metadata lock on function being dropped and now
waits for other conflicting metadata lock to go away.
mysql-test/t/mdl_sync.test:
Added test coverage for some aspects of deadlock handling in
metadata locking subsystem.
Adjusted test case after removing back-off in general case
when conflicting metadata lock is encountered during
open_tables() (now this happens only if waiting for
conflicting lock to go away leads to a deadlock).
mysql-test/t/sp_sync.test:
Adjusted test case after removing back-off in general case
when conflicting metadata lock is encountered during
open_tables() (now this happens only if waiting for
conflicting lock to go away leads to a deadlock).
sql/mdl.cc:
Changed MDL subsystem to support new approach to acquring
metadata locks in open tables and more fair and efficient
scheduling of metadata locks. To implement this:
- Made releasing of the lock and granting it to the most
appropriate pending request atomic operation. As result it
became possible to wake up only those waiters requests from
which can be satisfied at the moment as well as wake-up
only one waiter in case when granting its request would
prevent all other requests from being satisfied.
This solved thundering herd problem which occured in cases
when we were releasing some lock and woke up many waiters
for SNRW or X locks (this was the issue in Bug #52289
"performance regression for MyISAM in sysbench OLTP_RW
test".
To emphasize above changes wake_up_waiters() was renamed
to MDL_context::reschedule_waiters().
- Changed code to add tickets for new requests to the back of
waiters queue and to select tickets to be satisfied from
the head of the queue if possible (this makes scheduling of
requests with the same priority fair). To be able to do
this efficiently we now use for waiting and granted queues
version of I_P_List class which provides fast push_back()
method.
- Members and methods of MDL_context related to sending
and waiting for signal were moved to separate MDL_wait
class.
- Since in order to avoid race conditions we must grant the
lock only to the context which was not chosen as a victim
of deadlock, killed or aborted due to timeout
MDL_wait::set_status() (former awake()) was changed not to
send signal if signal slot is already occupied and to
indicate this fact through its return value. As another
consequence MDL_wait::timed_wait() method was changed to
handle timeout (optionally) and abort due to kill as
signals which make signal slot occupied.
- Renamed MDL_context::acquire_lock_impl() to acquire_lock().
Changed it to be able correctly process requests for shared
locks when there are open HANDLERs, made this method more
optimized for acquisition of shared locks. As part of this
change moved code common between try_acquire_lock() and
acquire_lock() to new try_acquire_lock_impl() method.
Also adjusted acquire_lock()'s code to take into account
the fact that in cases when lock is granted as result of
MDL_context::reschedule_waiters() call (i.e. when it is
granted after waiting for lock conflict to go away)
updating MDL_lock state is responsibility of the thread
calling reschedule_waiters().
- Changed MDL_context::find_deadlock() to send VICTIM
signal even if victim is the context which has initiated
deadlock detection. This is required in order to avoid
races in cases when the same context simultaneously is
chosen as a victim and its request for lock is satisfied.
As result return value of this method became unnecessary
and it was changed to return void.
Adjusted MDL_lock::find_deadlock() method to take into
account that now there can be a discrepancy between
MDL_context::m_waiting_for value being set and real state
of the ticket this member points to.
- Renamed MDL_context::m_waiting_for_lock to m_LOCK_waiting_for
and MDL_context::stop_waiting() to done_waiting_for().
- Finally, removed MDL_context::wait_for_lock() method.
sql/mdl.h:
Changed MDL subsystem to support new approach to acquring
metadata locks in open tables and more fair and efficient
scheduling of metadata locks. To implement this:
- Members and methods of MDL_context related to sending
and waiting for signal were moved to separate MDL_wait
class.
- Since now in order to avoid race conditions we must grant
the lock only to the context which was not chosen as a
victim of deadlock, killed or aborted due to timeout
MDL_wait::set_status (former awake()) was changed not to
send signal if signal slot is already occupied and to
indicate this fact through its return value.
Also NORMAL_WAKE_UP signal became GRANTED, and timeouts
and aborts due to kill became full blown signals rather
than simple return values.
- MDL_wait::timed_wait() now takes extra parameter that
indicates whether signal should be set if timeout is
reached.
- Enabled fast push_back() operation in MDL_context::m_tickets
list to make move_ticket_after_trans_sentinel() method more
efficient.
- Removed MDL_context::wait_for_lock() method.
- Renamed MDL_context::m_waiting_for_lock to m_LOCK_waiting_for
and MDL_context::stop_waiting() to done_waiting_for().
- MDL_context::acquire_lock_impl() became acquire_lock().
- Introduced MDL_context::try_acquire_lock_impl() as a
place for code shared by try_acquire_lock and
acquire_lock().
- Due to fact that now VICTIM signal is sent even if victim
is the context which has initiated deadlock detection
find_deadlock() no longer needs a return value.
sql/sql_base.cc:
Implemented new approach to acquiring metadata locks in
open_tables(). We no longer perform back-off when conflicting
metadata lock is encountered. Instead we wait for this lock
to go away while holding all locks which were acquired so
far. Back-off is only used in situation when further waiting
will cause a deadlock which could be avoided by performing
back-off and restarting open_tables() process. Absence of
waiting between back-off and restart of acquiring metadata
locks can't lead to livelocks as MDL subsystem was changed
to make release of lock and granting it to waiting lock
an atomic action, so back-off will automatically give way
to other participants of deadlock loop.
Accordingly:
- open_table_get_mdl_lock() and open_and_process_routine()
were changed to wait for conflicting metadata lock to
go away without back-off. Only if such wait leads to a
deadlock back-off is requested. As part of this change
new error handler class was introduced which converts,
if possible, ER_LOCK_DEADLOCK error to a request for
back-off and re-start of open_tables() process.
- Open_table_context::recover_from_failed_open() was changed
not to wait in case of metadata lock conflict. Instead we
immediately proceed to re-acquiring locks.
- Open_table_context::request_backoff_action() now always
emits error if back-off is requested in the middle of
transaction as we can't be sure that releasing lock
which were acquired only by current statement will
resolve a deadlock. Before this patch such situations were
successfully detected thanks to the fact that we called
MDL_context::wait_for_lock() method in
recover_from_failed_open().
- In order to avoid deadlocks open_tables() code was adjusted
to flush open HANDLERs for which there are pending requests
for X locks before restarting the process of acquiring
metadata locks.
- Changed close_tables_for_reopen() not to reset MDL_request
for tables belonging to the tail of prelocking list. It is
no longer necessary as these MDL_request objects won't be
used for any waiting.
- Adjusted comment in tdc_wait_for_old_version() to avoid
mentioning removed MDL_context::wait_for_lock() method.
sql/sql_base.h:
As we no longer wait for conflicting metadata lock away in
Open_table_context::recover_from_failed_open() method,
Open_table_context::OT_WAIT_MDL_LOCK action was renamed to
OT_MDL_CONFLICT.
Also Open_table_context::m_failed_mdl_request became
unnecessary and was removed.
sql/sql_plist.h:
Extended I_P_List template to support efficient push_back()
operation if it is parameterized with an appropriate policy
class.
sql/sql_show.cc:
Adjusted code after removal of MDL_context::wait_for_lock()
method. Now if one needs to acquire metadata lock with waiting
one has to use a variant of MDL_context::acquire_lock() method.
