Commit graph

1374 commits

Author SHA1 Message Date
Jon Olav Hauglid
8f73bddc9a Merge from mysql-5.5-bugteam to mysql-5.5-runtime
No conflicts
2010-10-19 11:26:45 +02:00
Jon Olav Hauglid
1bb2c68bfa Merge from mysql-5.5-bugteam to mysql-5.5-runtime
No conflicts
2010-10-19 11:26:45 +02:00
unknown
c20cbe5b4a Manual merge 2010-10-16 22:20:35 +08:00
b1b7e534ef Manual merge 2010-10-16 22:20:35 +08:00
unknown
211552ccee Bug#56118 STOP SLAVE does not wait till trx with CREATE TMP TABLE ends,
replication aborts

When recieving a 'SLAVE STOP' command, slave SQL thread will roll back the
transaction and stop immidiately if there is only transactional table updated,
even through 'CREATE|DROP TEMPOARY TABLE' statement are in it. But These
statements can never be rolled back. Because the temporary tables to the user
session mapping remain until 'RESET SLAVE', Therefore it will abort SQL thread
with an error that the table already exists or doesn't exist, when it restarts
and executes the whole transaction again.

After this patch, SQL thread always waits till the transaction ends and then stops,
if 'CREATE|DROP TEMPOARY TABLE' statement are in it.

mysql-test/extra/rpl_tests/rpl_stop_slave.test:
  Auxiliary file which is used to test this bug.
mysql-test/suite/rpl/t/rpl_stop_slave.test:
  Test case for this bug.
sql/slave.cc:
  Checking if OPTION_KEEP_LOG is set. If it is set, SQL thread should wait
  until the transaction ends.
sql/sql_parse.cc:
  Add a debug point for testing this bug.
2010-10-16 20:03:44 +08:00
131e3e38fd Bug#56118 STOP SLAVE does not wait till trx with CREATE TMP TABLE ends,
replication aborts

When recieving a 'SLAVE STOP' command, slave SQL thread will roll back the
transaction and stop immidiately if there is only transactional table updated,
even through 'CREATE|DROP TEMPOARY TABLE' statement are in it. But These
statements can never be rolled back. Because the temporary tables to the user
session mapping remain until 'RESET SLAVE', Therefore it will abort SQL thread
with an error that the table already exists or doesn't exist, when it restarts
and executes the whole transaction again.

After this patch, SQL thread always waits till the transaction ends and then stops,
if 'CREATE|DROP TEMPOARY TABLE' statement are in it.
2010-10-16 20:03:44 +08:00
Davi Arnaut
1d43e72a0b Bug#56096: STOP SLAVE hangs if executed in parallel with user sleep
The root of the problem is that to interrupt a slave SQL thread
wait, the STOP SLAVE implementation uses thd->awake(THD::NOT_KILLED).
This appears as a spurious wakeup (e.g. from a sleep on a
condition variable) to the code that the slave SQL thread is
executing at the time of the STOP. If the code is not written
to be spurious-wakeup safe, unexpected behavior can occur. For
the reported case, this problem led to an infinite loop around
the interruptible_wait() function in item_func.cc (SLEEP()
function implementation).  The loop was not being properly
restarted and, consequently, would not come to an end. Since the
SLEEP function sleeps on a timed event in order to be killable
and to perform periodic checks until the requested time has
elapsed, the spurious wake up was causing the requested sleep
time to be reset every two seconds.

The solution is to calculate the requested absolute time only
once and to ensure that the thread only sleeps until this
time is elapsed. In case of a spurious wake up, the sleep is
restarted using the previously calculated absolute time. This
restores the behavior present in previous releases. If a slave
thread is executing a SLEEP function, a STOP SLAVE statement
will wait until the time requested in the sleep function
has elapsed.

mysql-test/extra/rpl_tests/rpl_start_stop_slave.test:
  Add test case for Bug#56096.
mysql-test/suite/rpl/r/rpl_stm_start_stop_slave.result:
  Add test case result for Bug#56096.
sql/item_func.cc:
  Reorganize interruptible_wait into a class so that the absolute
  time can be preserved across calls to the wait function. This
  allows the sleep to be properly restarted in the presence of
  spurious wake ups, including those generated by a STOP SLAVE.
2010-10-13 22:54:07 -03:00
Davi Arnaut
7d64c36486 Bug#56096: STOP SLAVE hangs if executed in parallel with user sleep
The root of the problem is that to interrupt a slave SQL thread
wait, the STOP SLAVE implementation uses thd->awake(THD::NOT_KILLED).
This appears as a spurious wakeup (e.g. from a sleep on a
condition variable) to the code that the slave SQL thread is
executing at the time of the STOP. If the code is not written
to be spurious-wakeup safe, unexpected behavior can occur. For
the reported case, this problem led to an infinite loop around
the interruptible_wait() function in item_func.cc (SLEEP()
function implementation).  The loop was not being properly
restarted and, consequently, would not come to an end. Since the
SLEEP function sleeps on a timed event in order to be killable
and to perform periodic checks until the requested time has
elapsed, the spurious wake up was causing the requested sleep
time to be reset every two seconds.

The solution is to calculate the requested absolute time only
once and to ensure that the thread only sleeps until this
time is elapsed. In case of a spurious wake up, the sleep is
restarted using the previously calculated absolute time. This
restores the behavior present in previous releases. If a slave
thread is executing a SLEEP function, a STOP SLAVE statement
will wait until the time requested in the sleep function
has elapsed.
2010-10-13 22:54:07 -03:00
Dmitry Lenev
ec505e9570 Fix for bug #57422 "rpl_row_sp003 sporadically fails under
heavy load".

rpl_row_sp003.test has sporadically failed when run on machine
under heavy load or on slow hardware.

This patch fixes races in the test which were causing these
failures and also removes unnecessary 100 second wait from it.
2010-10-13 15:21:45 +04:00
Dmitry Lenev
8007ef52f1 Fix for bug #57422 "rpl_row_sp003 sporadically fails under
heavy load".

rpl_row_sp003.test has sporadically failed when run on machine
under heavy load or on slow hardware.

This patch fixes races in the test which were causing these
failures and also removes unnecessary 100 second wait from it.
2010-10-13 15:21:45 +04:00
unknown
56edc1df7c Manual merge 2010-10-09 18:18:16 +08:00
a667ce8e27 Manual merge 2010-10-09 18:18:16 +08:00
Alfranio Correia
8504580ced BUG#56343 binlog_cache_use status is bigger than expected
The binlog_cache_use is incremented twice when changes to a transactional table
are committed, i.e. TC_LOG_BINLOG::log_xid calls is called. The problem happens
because log_xid calls both binlog_flush_stmt_cache and binlog_flush_trx_cache
without checking if such caches are empty thus unintentionally increasing the
binlog_cache_use value twice.

To fix the problem we avoided incrementing the binlog_cache_use if the cache is
empty. We also decided to increment binlog_cache_use when the cache is truncated
as the cache is used although its content is discarded and is not written to the
binary log.

Note that binlog_cache_use is incremented for both types of cache, transactional
and non-transactional and that the behavior presented in this patch also applies
to the binlog_cache_disk_use.

Finally, we re-organized the code around the functions binlog_flush_trx_cache and
binlog_flush_stmt_cache.

mysql-test/extra/binlog_tests/binlog_cache_stat.test:
  Updated the test case with comments and additional tests to check both
  transactional and non-transactional changes and what happens when a 
  is transaction either committed or aborted.
mysql-test/suite/binlog/r/binlog_innodb.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_mixed_cache_stat.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_row_cache_stat.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_stm_cache_stat.result:
  Updated the result file.
mysql-test/suite/binlog/t/binlog_mixed_cache_stat.test:
  Updated the test case with a new source file.
mysql-test/suite/binlog/t/binlog_row_cache_stat.test:
  Updated the test case with a new source file.
mysql-test/suite/binlog/t/binlog_stm_cache_stat.test:
  Updated the test case with a new source file.
sql/log_event.cc:
  Introduced debug information to check if Query_log_event("BEGIN"),
  Query_log_event("COMMIT") and Query_log_event("ROLLBACK").
sql/log_event.h:
  Guaranteed Xid_log_event is always classified as a transactional event.
2010-10-06 09:34:49 +01:00
Alfranio Correia
0be27d8f1c BUG#56343 binlog_cache_use status is bigger than expected
The binlog_cache_use is incremented twice when changes to a transactional table
are committed, i.e. TC_LOG_BINLOG::log_xid calls is called. The problem happens
because log_xid calls both binlog_flush_stmt_cache and binlog_flush_trx_cache
without checking if such caches are empty thus unintentionally increasing the
binlog_cache_use value twice.

To fix the problem we avoided incrementing the binlog_cache_use if the cache is
empty. We also decided to increment binlog_cache_use when the cache is truncated
as the cache is used although its content is discarded and is not written to the
binary log.

Note that binlog_cache_use is incremented for both types of cache, transactional
and non-transactional and that the behavior presented in this patch also applies
to the binlog_cache_disk_use.

Finally, we re-organized the code around the functions binlog_flush_trx_cache and
binlog_flush_stmt_cache.
2010-10-06 09:34:49 +01:00
unknown
89f3fec1e3 Bug #54579 Wrong unsafe warning for INSERT DELAYED in SBR
The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for
INSERT DELAYED when inserting multi values in one statement.
It's safe. But it causes an unsafe warning in SBR.
      
Make INSERT DELAYED safe by logging it as INSERT without DELAYED.


mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
  Updated the test file to test multi INSERT DELAYED statement
  is no longer causes an unsafe warning and binlogged as INSERT
  without DELAYED.
mysql-test/extra/rpl_tests/create_recursive_construct.inc:
  Updated for the patch of bug#54579.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
  Updated for the patch of bug#54579.
mysql-test/suite/binlog/r/binlog_statement_insert_delayed.result:
  Test result for BUG#54579.
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
  Updated for the patch of bug#54579.
mysql-test/suite/binlog/r/binlog_unsafe.result:
  Updated for the patch of bug#54579.
mysql-test/suite/binlog/t/binlog_unsafe.test:
  Updated for the patch of bug#54579.
sql/sql_insert.cc:
  Added code to genetate a new query string for removing
  DELAYED keyword for multi INSERT DEALAYED statement.
sql/sql_yacc.yy:
  Added code to record the DELAYED keyword position and remove the setting
  of unsafe statement for INSERT DELAYED statement
2010-08-30 14:03:28 +08:00
0688c086a0 Bug #54579 Wrong unsafe warning for INSERT DELAYED in SBR
The lock_type is upgrade to TL_WRITE from TL_WRITE_DELAYED for
INSERT DELAYED when inserting multi values in one statement.
It's safe. But it causes an unsafe warning in SBR.
      
Make INSERT DELAYED safe by logging it as INSERT without DELAYED.
2010-08-30 14:03:28 +08:00
Jon Olav Hauglid
02863b4180 Merge from mysql-5.5-runtime to mysql-5.5-bugfixing. 2010-08-20 10:24:32 +02:00
Alfranio Correia
ac6026ce27 BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with
temp table
            
This patch introduces two key changes in the replication's behavior.
            
Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
into the trx-cache. Now, updates to temporary tables are handled according to
the type of their engines as a regular table.
            
Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
table as well non-transactional or temporary table, and writes to any of them),
are written into the trx-cache in order to minimize errors in the execution when
the statement logging format is in use.
            
Such changes has a direct impact on which statements are classified as unsafe
statements and thus part of BUG#53259 is reverted.
2010-08-20 03:59:58 +01:00
Jon Olav Hauglid
39ac44d660 Merge from mysql-5.5-runtime to mysql-5.5-bugfixing. 2010-08-20 10:24:32 +02:00
Alfranio Correia
c6d4915f3c BUG#53452 Inconsistent behavior of binlog_direct_non_transactional_updates with
temp table
            
This patch introduces two key changes in the replication's behavior.
            
Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
into the trx-cache. Now, updates to temporary tables are handled according to
the type of their engines as a regular table.
            
Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
table as well non-transactional or temporary table, and writes to any of them),
are written into the trx-cache in order to minimize errors in the execution when
the statement logging format is in use.
            
Such changes has a direct impact on which statements are classified as unsafe
statements and thus part of BUG#53259 is reverted.
2010-08-20 03:59:58 +01:00
Jon Olav Hauglid
f2123f34e3 Merge from mysql-5.5-bugfixing to mysql-5.5-runtime 2010-08-18 13:55:37 +02:00
Jon Olav Hauglid
8f36eaa11e Merge from mysql-5.5-bugfixing to mysql-5.5-runtime 2010-08-18 13:55:37 +02:00
unknown
d0d8bbed5e WL#5370 Keep forward-compatibility when changing
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
automatically after the this patch.
BUG#55617 is fixed by this patch too.
            
This is the 5.5 part.
It implements:
- 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
  anything and binlog anything if the table already exists.
  It only generate a warning that table already exists.
- A couple of test cases for the behavior changing.
2010-08-18 17:35:41 +08:00
d3b7cd3ff2 WL#5370 Keep forward-compatibility when changing
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
automatically after the this patch.
BUG#55617 is fixed by this patch too.
            
This is the 5.5 part.
It implements:
- 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
  anything and binlog anything if the table already exists.
  It only generate a warning that table already exists.
- A couple of test cases for the behavior changing.
2010-08-18 17:35:41 +08:00
unknown
9d6811502e WL#5370 Keep forward-compatibility when changing
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.

This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT

- Insert nothing and binlog nothing on master if the existing object
  is a view. It only generates a warning that table already exists.


mysql-test/r/trigger.result:
  Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not
  insert anything if the creating table already exists and is a view.
sql/sql_class.h:
  Declare virtual function write_to_binlog() for select_insert.
  It's used to binlog 'create select'
sql/sql_insert.cc:
  Implement write_to_binlog();
  Use write_to_binlog() instead of binlog_query() to binlog the statement.
  if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT
sql/sql_lex.h:
  Declare create_select_start_with_brace and create_select_pos.
  They are helpful for binlogging 'create select'
sql/sql_parse.cc:
  Do nothing on master if the existing object is a view.
sql/sql_yacc.yy:
  Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement.
  Record whether there is a '(' before the 'SELECT' clause.
2010-08-18 12:56:06 +08:00
b766a51f41 WL#5370 Keep forward-compatibility when changing
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.

This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
  and INSERT ... SELECT

- Insert nothing and binlog nothing on master if the existing object
  is a view. It only generates a warning that table already exists.
2010-08-18 12:56:06 +08:00
Jon Olav Hauglid
7c3de33a4f Merge from mysql-5.5-bugfixing to mysql-5.5-runtime. 2010-08-13 10:43:26 +02:00
Jon Olav Hauglid
f8372252dd Merge from mysql-5.5-bugfixing to mysql-5.5-runtime. 2010-08-13 10:43:26 +02:00
Alfranio Correia
88b3205653 BUG#50312 Warnings for unsafe sub-statement not returned to client
After BUG#36649, warnings for sub-statements are cleared when a 
new sub-statement is started. This is problematic since it suppresses
warnings for unsafe statements in some cases. It is important that we
always give a warning to the client, because the user needs to know
when there is a risk that the slave goes out of sync.
                        
We fixed the problem by generating warning messages for unsafe statements
while returning from a stored procedure, function, trigger or while
executing a top level statement.
                        
We also started checking unsafeness when both performance and log tables are
used. This is necessary after the performance schema which does a distinction
between performance and log tables.

mysql-test/extra/rpl_tests/create_recursive_construct.inc:
  Changed the order of the calls in the procedure because the code
  that checks if a warning message is printed out expects that the
  first statement gives an warning what is not the case for INSERT
  INTO ta$CRC_ARG_level VALUES (47);
mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result:
  Updated the result file.
mysql-test/suite/binlog/r/binlog_unsafe.result:
  There are several changes here:
          
  (1) - Changed the CREATE PROCEDURE $CRC.
                                  
  (2) - The procedure $CRC was failing and the content of the binlog
        was being printed out, after fix (1) the failure disappeared.
                                  
  (3) - The warning message for unsafeness due to auto-increment collumns was
        changed.
                                  
  (4) - The warning message for unsafeness due to VERSION(), RAND() was changed.
mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test:
  Tested filters.
mysql-test/suite/binlog/t/binlog_unsafe.test:
  Reenabled the test case binlog_unsafe.
mysql-test/suite/binlog/t/disabled.def:
  Reenabled the test case binlog_unsafe.
mysql-test/suite/rpl/r/rpl_begin_commit_rollback.result:
  Updated the result file.
mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result:
  Updated the result file.
mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result:
  Updated the result file.
sql/sql_class.cc:
  Moved the stmt_accessed_table_flag variable and related information to the
  LEX as we need the variable reset after each statement even inside a stored
  procedure, what did not happen if the information was in the THD.
          
  Changed the routine in the THD::binlog_query that prints the warning
  messages to avoid trying to print them when inside a stored procedure,
  function or trigger.
                          
  Checked for unsafeness when both performance and log tables where used.
  After the introduction of the performance schema, we need to check both.
2010-08-10 12:32:54 +01:00
Alfranio Correia
bd3aa7eb78 BUG#50312 Warnings for unsafe sub-statement not returned to client
After BUG#36649, warnings for sub-statements are cleared when a 
new sub-statement is started. This is problematic since it suppresses
warnings for unsafe statements in some cases. It is important that we
always give a warning to the client, because the user needs to know
when there is a risk that the slave goes out of sync.
                        
We fixed the problem by generating warning messages for unsafe statements
while returning from a stored procedure, function, trigger or while
executing a top level statement.
                        
We also started checking unsafeness when both performance and log tables are
used. This is necessary after the performance schema which does a distinction
between performance and log tables.
2010-08-10 12:32:54 +01:00
Dmitry Lenev
8d0dc9b58b Part of fix for bug#52044 "FLUSH TABLES WITH READ LOCK and
FLUSH TABLES <list> WITH READ LOCK are incompatible" to
be pushed as separate patch.

Replaced thread state name "Waiting for table", which was
used by threads waiting for a metadata lock or table flush, 
with a set of names which better reflect types of resources
being waited for.

Also replaced "Table lock" thread state name, which was used 
by threads waiting on thr_lock.c table level lock, with more
elaborate "Waiting for table level lock", to make it 
more consistent with other thread state names.

Updated test cases and their results according to these 
changes.

Fixed sys_vars.query_cache_wlock_invalidate_func test to not
to wait for timeout of wait_condition.inc script.

mysql-test/r/query_cache.result:
  Added test coverage for query_cache_wlock_invalidate
  behavior for implicitly locked tables.
mysql-test/suite/sys_vars/r/query_cache_wlock_invalidate_func.result:
  Fixed sys_vars.query_cache_wlock_invalidate_func test to not
  to wait for timeout of wait_condition.inc script. Reverted
  changes to test which introduced timeout and replaced waiting
  condition with a more appropriate one.
  Test coverage for query_cache_wlock_invalidate behavior for
  implicitly locked tables was added to query_cache.test.
mysql-test/suite/sys_vars/t/query_cache_wlock_invalidate_func.test:
  Fixed sys_vars.query_cache_wlock_invalidate_func test to not
  to wait for timeout of wait_condition.inc script. Reverted
  changes to test which introduced timeout and replaced waiting
  condition with a more appropriate one.
  Test coverage for query_cache_wlock_invalidate behavior for
  implicitly locked tables was added to query_cache.test.
mysql-test/t/query_cache.test:
  Added test coverage for query_cache_wlock_invalidate
  behavior for implicitly locked tables.
mysys/thr_lock.c:
  Replaced "Table lock" thread state name, which was used by 
  threads waiting on thr_lock.c table level lock, with more
  elaborate "Waiting for table level lock", to make it 
  consistent with thread state names which are used while
  waiting for metadata locks and table flush.
sql/mdl.cc:
  Replaced thread state name "Waiting for table", which was
  used by threads waiting for a metadata lock or table flush, 
  with a set of names which better reflect types of resources
  being waited for. 
  
  To implement this:
  - Adjusted MDL_wait::timed_wait() to take thread state name
    as parameter.
  - Introduced method of MDL_key class which allows to get
    thread state name to be used while waiting for resource
    corresponding to the key and changed code to use it.
    Added array translating namespaces to thread state names
    as part of this change.
sql/mdl.h:
  To implement this:
  - Adjusted MDL_wait::timed_wait() to take thread state name
    as parameter.
  - Introduced method of MDL_key class which allows to get
    thread state name to be used while waiting for resource
    corresponding to the key and changed code to use it.
    Added array translating namespaces to thread state names
    as part of this change.
sql/sql_base.cc:
  Replaced thread state name "Waiting for table", which was
  used by threads waiting for table flush, with a more elaborate
  "Waiting for table flush".
2010-08-06 15:29:37 +04:00
Dmitry Lenev
a6c00c276e Part of fix for bug#52044 "FLUSH TABLES WITH READ LOCK and
FLUSH TABLES <list> WITH READ LOCK are incompatible" to
be pushed as separate patch.

Replaced thread state name "Waiting for table", which was
used by threads waiting for a metadata lock or table flush, 
with a set of names which better reflect types of resources
being waited for.

Also replaced "Table lock" thread state name, which was used 
by threads waiting on thr_lock.c table level lock, with more
elaborate "Waiting for table level lock", to make it 
more consistent with other thread state names.

Updated test cases and their results according to these 
changes.

Fixed sys_vars.query_cache_wlock_invalidate_func test to not
to wait for timeout of wait_condition.inc script.
2010-08-06 15:29:37 +04:00
unknown
bcb3170c97 Bug #34283 mysqlbinlog leaves tmpfile after termination if binlog contains load data infile
With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.

To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.




mysql-test/extra/rpl_tests/rpl_loaddata.test:
  Updated for Bug#34283
mysql-test/suite/binlog/r/binlog_mixed_load_data.result:
  Test result for BUG#34283.
mysql-test/suite/binlog/t/binlog_killed_simulate.test:
  Updated for Bug#34283
mysql-test/suite/binlog/t/binlog_mixed_load_data.test:
  Added the test file to verify that 'load data infile...' statement
  will go to row-based in mixed mode.
mysql-test/suite/binlog/t/binlog_stm_blackhole.test:
  Updated for Bug#34283
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_fatal.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_loaddata_map.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
  Updated for Bug#34283
mysql-test/suite/rpl/t/rpl_stm_log.test:
  Updated for Bug#34283
sql/sql_load.cc:
  Added code to go to row-based in mixed mode for
  'load data infile ...' statement
2010-08-03 10:22:19 +08:00
aa1572f46d Bug #34283 mysqlbinlog leaves tmpfile after termination if binlog contains load data infile
With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.

To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.
2010-08-03 10:22:19 +08:00
Michael Widenius
e0a6b02c5d Merge with MySQL 5.1.49
Fixed Bug#52005 'JOIN_TAB->dependent' may be incorrectly propageted for multilevel outer joins' in a better way (patch from Sergey Petrunya)
2010-08-02 12:01:24 +03:00
Andrei Elkin
b283ffcd53 merging for bug#54935 to trunk-bugfixing 2010-07-17 14:07:36 +03:00
Andrei Elkin
c225cde943 merging for bug#54935 to trunk-bugfixing 2010-07-17 14:07:36 +03:00
Andrei Elkin
65ef0f4185 bug#54935
applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug
2010-07-16 21:25:38 +03:00
Andrei Elkin
2d91f05e88 bug#54935
applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug
2010-07-16 21:25:38 +03:00
Andrei Elkin
30e2c6f19b bug#54935
applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug
2010-07-16 21:25:00 +03:00
Andrei Elkin
48d1c50ac1 bug#54935
applying bundle made for next-mr-bugfixing to trunk-bugfixing branch of the bug
2010-07-16 21:25:00 +03:00
Luis Soares
b84b607e87 BUG 54842: automerged bzr bundle in mysql-trunk-bugfixing. 2010-07-07 23:27:52 +01:00
Luis Soares
8794236100 BUG 54842: automerged bzr bundle in mysql-trunk-bugfixing. 2010-07-07 23:27:52 +01:00
Alfranio Correia
68ecc965a6 WL#5344 2010-06-30 20:37:41 +01:00
Alfranio Correia
34664b6abb WL#5344 2010-06-30 20:37:41 +01:00
Alfranio Correia
c9221a2a6f BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables
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.
2010-06-30 16:25:13 +01:00
Alfranio Correia
e662b51eef BUG#53259 Unsafe statement binlogged in statement format w/MyIsam temp tables
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.
2010-06-30 16:25:13 +01:00
Luis Soares
e0ece40b64 BUG#54842: DROP TEMPORARY TABLE not binlogged after manual
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.
2010-06-29 11:54:58 +01:00
Luis Soares
bf261cdb6f BUG#54842: DROP TEMPORARY TABLE not binlogged after manual
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.
2010-06-29 11:54:58 +01:00
Konstantin Osipov
cc6dabba37 Merge trunk-bugfixing -> trunk-runtime 2010-06-17 17:31:51 +04:00