In RBR, All statements operating on temporary tables should not be binlogged.
Despite this fact, after executing 'TRUNCATE... ' on a temporary table,
the command is still logged, even if in row-based mode. Consequently, this raises
problems in the slave as the table may not exist, resulting in an
execution failure. Ultimately, this causes the slave to report
an error and abort.
After this patch, 'TRUNCATE ...' statement on a temporary table will not be
binlogged in RBR.
beyond unsigned long.
BUG#44779: binlog.binlog_max_extension may be causing failure on
next test in PB
NOTE1: this is the backport to next-mr.
NOTE2: already includes patch for BUG#44779.
Binlog file extensions would turn into negative numbers once the
variable used to hold the value reached maximum for signed
long. Consequently, incrementing value to the next (negative) number
would lead to .000000 extension, causing the server to fail.
This patch addresses this issue by not allowing negative extensions
and by returning an error on find_uniq_filename, when the limit is
reached. Additionally, warnings are printed to the error log when the
limit is approaching. FLUSH LOGS will also report warnings to the
user, if the extension number has reached the limit. The limit has been
set to 0x7FFFFFFF as the maximum.
left join
When creating a temporary TEXT/BLOB field from an Item in
Item::make_string_field(), the field's type was unconditionally
set to the one corresponding to the maximum length (i.e.
LONGTEXT/ LONGBLOB). This resulted in problems when exactly the
same TEXT/BLOB is type required in cases like CREATE ... SELECT
or creating internal temporary tables for joins.
Fixed by calling a different constructor for Field_blob so that
an appropriate type is used depending on the Item's max_length
value.
The problem is that the server could crash when attempting
to access a non-conformant proc system table. One such case
was a crash when invoking stored procedure related statements
on a 5.1 server with a proc system table in the 5.0 format.
The solution is to validate the proc system table format
before attempts to access it are made. If the table is not
in the format that the server expects, a message is written
to the error log and the statement that caused the table to
be accessed fails.
This is the non-ndb part of the patch.
The return value of mysql_bin_log.write was ignored by most callers,
which may lead to inconsistent on master and slave if the transaction
was committed while the binlog was not correctly written. If
my_error() is call in mysql_bin_log.write, this could also lead to
assertion issue if my_ok() or my_error() is called after.
This fixed the problem by let the caller to check and handle the
return value of mysql_bin_log.write. This patch only adresses the
simple cases.
------------------------------------------------------------
revno: 2572.23.1
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-03-19 09:03:08 -0300
message:
Bug#17954 Threads_connected > Threads_created
The problem is that insert delayed threads are counted as connected
but not as created, leading to a Threads_connected value greater then
the Threads_created value.
The solution is to enforce the documented behavior that the
Threads_connected value shall be the number of currently
open connections and that Threads_created shall be the
number of threads created to handle connections.
------------------------------------------------------------
revno: 2476.1116.1
committer: davi@mysql.com/endora.local
timestamp: Fri 2007-12-14 10:10:19 -0200
message:
DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES
WITH READ LOCK (global read lock) can lead to a deadlock.
The solution is to not wait for the global read lock if the
thread is holding any locked tables.
Related to bugs 23713 and 32395. This issues is being fixed
only on 6.0 because it depends on the fix for bug 25858 --
which was fixed only on 6.0.
------------------------------------------------------------
revno: 2476.784.3
committer: davi@moksha.local
timestamp: Tue 2007-10-02 21:27:31 -0300
message:
Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
When a client (connection) holds a lock on a table and attempts to
drop (obtain a exclusive lock) on a second table that is already
held by a second client and the second client then attempts to
drop the table that is held by the first client, leads to a
circular wait deadlock. This scenario is very similar to trying to
drop (or rename) a table while holding read locks and are
correctly forbidden.
The solution is to allow a drop table operation to continue only
if the table being dropped is write (exclusively) locked, or if
the table is temporary, or if the client is not holding any
locks. Using this scheme prevents the creation of a circular
chain in which each client is waiting for one table that the
next client in the chain is holding.
This is incompatible change, as can be seen by number of tests
cases that needed to be fixed, but is consistent with respect to
behavior of the different scenarios in which the circular wait
might happen.
The mentioned on the bug report set of bugs fixes have not be pushed to the main trees.
Fixed with extracting commits done to 6.0-rpl tree and applying them to the main 5.1.
Notes.
1. part of changes - the mtr's specific - were packported to the main 5.0 tree for mtr v1
as http://lists.mysql.com/commits/46562
However, there is no that fix anymore in the mtr v2. (This fact was mailed to mtr maintaining
people).
2. Bug@36929 crash in kill_zombie_dump_threads-> THD::awake() with replication tests
is not backported because the base code of the patch is libevent and that was removed
from the main trees due to its instability.
Bug #48370 Absolutely wrong calculations with GROUP BY and
decimal fields when using IF
Added the test cases in the above two bugs for regression
testing.
Added additional tests that demonstrate a incomplete fix.
Added a new factory method for Field_new_decimal to
create a field from an (decimal returning) Item.
In the new method made sure that all the precision and
length variables are capped in a proper way.
This is required because Item's can have larger precision
than the decimal fields and thus need to be capped when
creating a field based on an Item type.
Fixed the wrong typecast to Item_decimal.
When merging ranges during calculation of the result of OR
to two range sets the current range may be obsoleted by the
resulting merged range.
The first overlapping range can be obsoleted as well.
Fixed by moving the pointer to the first overlapping range to the
pointer of the resulting union range.
Added few comments at key places in key_or().
Problem: Some system functions that could return different values on
master and slave were not marked unsafe. In particular:
GET_LOCK
IS_FREE_LOCK
IS_USED_LOCK
MASTER_POS_WAIT
RELEASE_LOCK
SLEEP
SYSDATE
VERSION
Fix: Mark these functions unsafe.
Fixed a problem with the test case when executed with ps-protocol.
There the conflicing lock would be noticed during prepare, not
during execution of the insert - leading to a different (but
equally appropriate) error message.
DELETE IGNORE
The ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG error was set in the
diagnostics area when it happened, but the DELETE cleanup code
never checked for a non-fatal error condition, thus trying to
set diag.area to "ok". This triggered an assert checking that
the diag.area was empty.
The fix was to test if there existed a non-fatal error condition
(thd->is_error() before ok'ing the operation.
The problem was a "self-deadlock" if the connection issuing INSERT DELAYED
had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES
mode active. The table being inserted into had to be different from the
table(s) locked by LOCK TABLES.
For INSERT DELAYED, the connection thread waits until the handler thread has
opened and locked its table before returning. But since the global read lock
was active, the handler thread would be unable to lock and would wait for the
global read lock to go away.
So the handler thread would be waiting for the connection thread to release
the global read lock while the connection thread was waiting for the handler
thread to lock the table. This gave a "self-deadlock" (same connection,
different threads).
The deadlock would only happen if we also had LOCK TABLES mode since the
INSERT otherwise will try to get protection against global read lock before
starting the handler thread. It will then notice that the global read lock
is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK.
This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK
also if we are inside LOCK TABLES mode.
Test case added to delayed.test.
WHERE conditions
check_group_min_max() checks if the loose index scan
optimization is applicable for a given WHERE condition, that is
if the MIN/MAX attribute participates only in range predicates
comparing the corresponding field with constants.
The problem was that it considered the whole predicate suitable
for the loose index scan optimization as soon as it encountered
a constant as a predicate argument. This is obviously wrong for
cases when a constant is the first argument of a predicate
which does not satisfy the above condition.
Fixed check_group_min_max() so that all arguments of the input
predicate are considered to decide if it passes the test, even
though a constant has already been encountered.
MySQL manual describes values of the YEAR(2) field type as follows:
values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999
years. MIN/MAX and comparison functions was comparing them as int values
thus producing wrong result.
Now the Arg_comparator class is extended with compare_year function which
performs correct comparison of the YEAR type.
The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
correctly calculate its value.
To allow Arg_comparator to use func_name() function for Item_func and Item_sum
objects the func_name declaration is moved to the Item_result_field class.
A helper function is_owner_equal_func is added to the Arg_comparator class.
It checks whether the Arg_comparator object owner is the <=> function or not.
A helper function setup is added to the Item_sum_hybrid class. It sets up
cache item and comparator.
Post-push fix: Removed MTRv1 arguments according to the
original patch. Although there is a version check, the patch
was pushed to a 5.1 GA staging tree, while the version check
considers version 5.2. This makes the deprecated parameters
to be used, despite the fact that they are not valid anymore.
Part of MTRv1 is currently used in RQG semisync test, and this
was causing the test to fail on slave startup.
It should be safe to uncomment when merging up to celosia.
After fix of bug46322, logging to table is turned off, each test
that need this should turn on it in it's opt file.
Add suppression to unsafe statement warnings for binlog_unsafe.test.
init_read_record() - (records.cc:274)
Item_cond::used_tables_cache was accessed in
records.cc#init_read_record() without being initialized. It had
not been initialized because it was wrongly assumed that the
Item's variables would not be accessed, and hence
quick_fix_field() was used instead of fix_fields() to save a few
CPU cycles at creation time.
The fix is to properly initilize the Item by replacing
quick_fix_field() with fix_fields().
One statement that have more than one different tables to update with
autoinc columns just was marked as unsafe in mixed mode, so the unsafe
warning can't be produced in statement mode.
To fix the problem, mark the statement as unsafe in statement mode too.
This patch borrows ideas, text and code from Kristofer
Pettersson's patch.
An assignment of a system variable sharing the same base
name as a declared stored procedure variable in the same
context could lead to a crash.
The reason was that during the parsing of the syntactic
rule 'option_value' an uninitialized set_var object was
pushed to the parameter stack of the SET statement. The
parent rule 'option_type_value' interpreted the existence
of variables on the parameter stack as an assignment and
wrapped it in a sp_instr_set object.
As the procedure later was executed an attempt was made
to run the method 'check()' on an uninitialized member
object (NULL value) belonging to the previously created
but uninitialized object.
This patch refactors the 'internal_variable_name' rule and
copies the semantic analysis part to the depending parent
rule: 'option_value'. This makes it possible to account
for any prefixes affecting the interpretation of the
internal_variable_name.
Create a set of test cases to see if some DDL statements implicitly commit
a transaction on the NDB and are written directly to the binary log without
going through either the Statement- or Transactional-Cache.
Until-pos guarding did not distiguish the master originated events from ones that the slave
can introduce to the relay log e.g Rotate to the next relay log at slave restarting.
The local Rotate's coordinate are incomparable with the Until-master-pos.
That led to the unexpectable stop this bug describes.
Fixed with to avoid Until-master-pos comparison for a local slave's event.
Notice that if --replicate-same-server is true such event is treated as coming from
the master side.
deadlock was encountered
The bug is caused by an inconsistent handling of the IGNORE
clause. A read from a const table caused a lock timeout
(ER_LOCK_TIMEOUT) in innodb. Since the IGNORE clause was
given, the timeout was converted into a warning instead of
an error, thus not populating the diagnostics area. When
innodb subsequently marked the transaction for rollback,
mysql asserted since the diag.area was empty.
This patch consists of only a test case, as the bug itself
was fixed by the patch for Bug #46539
