> ------------------------------------------------------------
> revno: 2871.4.1
> revision-id: vvaintroub@mysql.com-20090429115110-1ye4700m8it5tyc5
> parent: staale.smedseng@sun.com-20090428161955-3vnku1igwt0knpfu
> committer: Vladislav Vaintroub <vvaintroub@mysql.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Wed 2009-04-29 13:51:10 +0200
> message:
> Bug#43932 myisam index corruption with large index and large
> key_buffer_size.
>
> The cause of corruption was number overflow when multiplying
> two ulong values, number of used keycache blocks with size
> of a single block. The result of multiplication exceeded ulong
> range (4G) and this lead to incorrectly calculated buffer offset
> in the key cache.
>
> The fix is to use size_t for multiplication result.
>
> This patch also fixes pointless cast in safemalloc
> (size of allocated block to uint), that creates lot of false
> alarm warnings when using big keycache (> 4GB) in debug mode.
> ------------------------------------------------------------
> revno: 2857.1.1
> revision-id: satya.bn@sun.com-20090415114608-26b21dtx3doeidcc
> parent: davi.arnaut@sun.com-20090414120532-9a34lwlk105z8log
> committer: Satya B <satya.bn@sun.com>
> branch nick: mysql-5.1-bugteam-innodb
> timestamp: Wed 2009-04-15 17:16:08 +0530
> message:
> Applying InnoDB snashot 5.1-ss4699, part 1. Fixes BUG#39320 and other
> problems
>
> 1) BUG#39320 - innodb crash in file btr/btr0pcur.c line 217 with
> innodb_locks_unsafe_for_binlog
>
> 2) Fixes bug in multi-table semi consistent reads.
>
> 3) Fixes email address from dev@innodb.com to innodb_dev_ww@oracle.com
>
> 4) Fixes warning message generated by main.innodb test
>
>
> Detailed revision comments:
>
> r4399 | marko | 2009-03-12 09:38:05 +0200 (Thu, 12 Mar 2009) | 5 lines
> branches/5.1: row_sel_get_clust_rec_for_mysql(): Store the cursor position
> also for unlock_row(). (Bug #39320)
>
> rb://96 approved by Heikki Tuuri.
>
> r4400 | marko | 2009-03-12 10:06:44 +0200 (Thu, 12 Mar 2009) | 8 lines
> branches/5.1: Fix a bug in multi-table semi-consistent reads.
> Remember the acquired record locks per table handle (row_prebuilt_t)
> rather than per transaction (trx_t), so that unlock_row should successfully
> unlock all non-matching rows in multi-table operations.
> This deficiency was found while investigating Bug #39320.
>
> rb://94 approved by Heikki Tuuri.
>
> r4481 | marko | 2009-03-19 15:01:48 +0200 (Thu, 19 Mar 2009) | 6 lines
> branches/5.1: row_unlock_for_mysql(): Do not unlock records that were
> modified by the current transaction. This bug was introduced or unmasked
> in r4400.
>
> rb://97 approved by Heikki Tuuri
>
> r4573 | vasil | 2009-03-30 14:17:13 +0300 (Mon, 30 Mar 2009) | 4 lines
> branches/5.1:
>
> Fix email address from dev@innodb.com to innodb_dev_ww@oracle.com
>
> r4574 | vasil | 2009-03-30 14:27:08 +0300 (Mon, 30 Mar 2009) | 38 lines
> branches/5.1:
>
> Restore the state of INNODB_THREAD_CONCURRENCY to silence this warning:
>
> TEST RESULT TIME (ms)
> ------------------------------------------------------------
>
> worker[1] Using MTR_BUILD_THREAD 250, with reserved ports 12500..12509
> main.innodb [ pass ] 8803
>
> MTR's internal check of the test case 'main.innodb' failed.
> This means that the test case does not preserve the state that existed
> before the test case was executed. Most likely the test case did not
> do a proper clean-up.
> This is the diff of the states of the servers before and after the
> test case was executed:
> mysqltest: Logging to '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.log'.
> mysqltest: Results saved in '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result'.
> mysqltest: Connecting to server localhost:12500 (socket /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
> mysqltest: ... Connected.
> mysqltest: Start processing test commands from './include/check-testcase.test' ...
> mysqltest: ... Done processing test commands.
> --- /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result 2009-03-30 14:12:31.000000000 +0300
> +++ /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.reject 2009-03-30 14:12:41.000000000 +0300
> @@ -99,7 +99,7 @@
> INNODB_SUPPORT_XA ON
> INNODB_SYNC_SPIN_LOOPS 20
> INNODB_TABLE_LOCKS ON
> -INNODB_THREAD_CONCURRENCY 8
> +INNODB_THREAD_CONCURRENCY 16
> INNODB_THREAD_SLEEP_DELAY 10000
> INSERT_ID 0
> INTERACTIVE_TIMEOUT 28800
>
> mysqltest: Result content mismatch
>
> not ok
>
> r4576 | vasil | 2009-03-30 16:25:10 +0300 (Mon, 30 Mar 2009) | 4 lines
> branches/5.1:
>
> Revert a change to Makefile.am that I committed accidentally in c4574.
> ------------------------------------------------------------
> revno: 2852.2.3
> revision-id: davi.arnaut@sun.com-20090403194600-60ufn0tz1gx1kl0l
> parent: gni@mysql.com-20090403184200-vnjtpsv4an79w8bu
> parent: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 43230-5.1
> timestamp: Fri 2009-04-03 16:46:00 -0300
> message:
> Merge Bug#43230 into mysql-5.1-bugteam
> ------------------------------------------------------------
> revno: 1810.3855.16
> revision-id: davi.arnaut@sun.com-20090403191154-0ho2nai3chjsmpof
> parent: chad@mysql.com-20090402152928-3ld60a56h86njcpg
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 43230-5.0
> timestamp: Fri 2009-04-03 16:11:54 -0300
> message:
> Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely
>
> The problem is that a SELECT .. FOR UPDATE statement might open
> a table and later wait for a impeding global read lock without
> noticing whether it is holding a table that is being waited upon
> the the flush phase of the process that took the global read
> lock.
>
> The same problem also affected the following statements:
>
> LOCK TABLES .. WRITE
> UPDATE .. SET (update and multi-table update)
> TRUNCATE TABLE ..
> LOAD DATA ..
>
> The solution is to make the above statements wait for a impending
> global read lock before opening the tables. If there is no
> impending global read lock, the statement raises a temporary
> protection against global read locks and progresses smoothly
> towards completion.
>
> Important notice: the patch does not try to address all possible
> cases, only those which are common and can be fixed unintrusively
> enough for 5.0.
> ------------------------------------------------------------
> revno: 2852.2.1
> revision-id: gni@mysql.com-20090403182157-de6ecrtzlgvpl5mk
> parent: timothy.smith@sun.com-20090402083720-b7i3jr4dmvwjakcj
> committer: Guangbao Ni <gni@mysql.com>
> branch nick: bugteam-5.1-bug42640
> timestamp: Fri 2009-04-03 18:21:57 +0000
> message:
> BUG#42640 mysqld crashes when unsafe statements are executed (STRICT_TRANS_TABLESmode)
>
> Mysql server crashes because unsafe statements warning is wrongly elevated to error,
> which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
> Yet the caller believes that binary logging shouldn't touch the status, so it will
> set the status also later by my_ok(), my_error() or my_message() seperately
> according to the execution result of the statement or transaction.
> But the status of Diagnostics_area of the thread is allowed to set only once.
>
> Fixed to clear the error wrongly set by binary logging, but keep the warning message.
> ------------------------------------------------------------
> revno: 2852.12.6
> tags: clone-5.1.35-build, mysql-5.1.35
> revision-id: gshchepa@mysql.com-20090513075139-g50shsfjaf1dstdn
> parent: joerg@mysql.com-20090508190407-ymqxmp6daeta6fdj
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: mysql-5.1
> timestamp: Wed 2009-05-13 12:51:39 +0500
> message:
> Bug #44290: explain crashes for subquery with distinct in
> SQL_SELECT::test_quick_select
>
> The crash was caused by an incomplete cleanup of JOIN_TAB::select
> during the filesort of rows for GROUP BY clause inside a subquery.
> Queries where a quick index access is replaced with filesort was
> was affected. For example:
>
> SELECT 1 FROM
> (SELECT COUNT(DISTINCT c1) FROM t1
> WHERE c2 IN (1, 1) AND c3 = 2 GROUP BY c2) x
>
> Quick index access related data in the SQL_SELECT::test_quick_select
> function was inconsistent after an incomplete cleanup.
> This function has been completed to prevent crashes in the
> SQL_SELECT::test_quick_select function.
> ------------------------------------------------------------
> revno: 2852.1.15
> revision-id: davi.arnaut@sun.com-20090409152525-b4vnj9atidmjh0mf
> parent: luis.soares@sun.com-20090409113044-2072kufy5efeohpp
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 43706-5.1
> timestamp: Thu 2009-04-09 12:25:25 -0300
> message:
> Bug#43706: libmysqld segfaults when re-intialised
> Bug#44091: libmysqld gets stuck waiting on mutex on initialization
>
> The problem was that libmysqld wasn't enforcing a certain
> initialization and deinitialization order for the mysys
> library. Another problem was that the global object used
> for management of log event handlers (aka LOGGER) wasn't
> being prepared for a possible reutilization.
>
> What leads to the hang/crash reported is that a failure
> to load the language file triggers a double call of the
> cleanup functions, causing an already destroyed mutex to
> be used.
>
> The solution is enforce a order on the initialization and
> deinitialization of the mysys library within the libmysqld
> library and to ensure that the global LOGGER object reset
> it's internal state during cleanup.
> ------------------------------------------------------------
> revno: 2841.1.1
> revision-id: sergey.glukhov@sun.com-20090401084033-161k4f8qucafy6mj
> parent: ramil@mysql.com-20090401053459-07x8z2pw2ev94xck
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Wed 2009-04-01 13:40:33 +0500
> message:
> Bug#43183 ExctractValue() brings result list in missorder
> The problem is that XML functions(items) do not reset null_value
> before their execution and further item excution may use
> null_value value of the previous result.
> The fix is to reset null_value.
> ------------------------------------------------------------
> revno: 1810.3885.1
> revision-id: holyfoot@mysql.com-20090428094726-i4j7z985mxr43jym
> parent: gshchepa@mysql.com-20090428001913-plzojd1pwplior44
> committer: Alexey Botchkov <holyfoot@mysql.com>
> branch nick: 50mrg
> timestamp: Tue 2009-04-28 14:47:26 +0500
> message:
> Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
> the Point() and Linestring() functions create WKB representation of an
> object instead of an real geometry object.
> That produced bugs when these were inserted into tables.
>
> GIS tests fixed accordingly.
>
> per-file messages:
> mysql-test/r/gis-rtree.result
> Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
> test result
> mysql-test/r/gis.result
> Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
> test result
> mysql-test/t/gis-rtree.test
> Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
> test fixed - GeomFromWKB invocations removed
> mysql-test/t/gis.test
> Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
> test fixed - AsWKB invocations added
> sql/item_geofunc.cc
> Bug#38990 Arbitrary data input plus GIS functions causes mysql server crash
> Point() and similar functions to create a proper object
The reason for the crash was rotate_relay_log (mi=0x0) did not verify
the passed value of active_mi. There are more cases where active_mi
is supposed to be non-zero e.g change_master(), stop_slave(), and it's
reasonable to protect from a similar crash all of them with common
fixes.
Fixed with spliting end_slave() in slave threads release and slave
data clean-up parts (a new close_active_mi()). The new function is
invoked at the very end of close_connections() so that all users of
active_mi are proven to have left.
sql/mysqld.cc:
added the 2nd part (data) of the slave's clean up.
sql/slave.cc:
end_slave() is split in two part to release the slave threads and the remained
resources separately.
The new close_active_mi() should be called after all possible users ofactive_mi
has left, i.e at the very end of close_connections().
sql/slave.h:
interface to the new end_active_mi() function is added.
queries if query was killed
Since we rely on thd->is_error() to decide whether we should
COMMIT or ROLLBACK after a query execution, check the query
'killed' state and throw an error before calling
ha_autocommit_or_rollback(), not after.
The patch was tested manually. For reliable results, the test
case would have to KILL QUERY while a DELETE/UPDATE query in
another thread is still running. I don't see a way to achieve
this kind of synchronization in our test suite (no debug_sync
in 5.1).
sql/sql_parse.cc:
Since we rely on thd->is_error() to decide whether we should
COMMIT or ROLLBACK after query execution, check the query
'killed' state and throw an error before calling
ha_autocommit_or_rollback(), not after.
When opening a table, it is imperative that the flag
TABLE::auto_increment_field_not_null be false. But if an error occured during
the creation of a table (e.g. the table exists already) with an auto_increment
column and a BEFORE trigger that used the INSERT ... SELECT construct, the
flag was not reset until after error checking. Thus if an error occured,
select_insert::send_data() returned immediately and it was not reset (see * in
pseudocode below). Crash happened if the table was opened again. Fixed by
resetting the flag after error checking.
nested-loops_join():
for each row in SELECT table {
select_insert::send_data():
if a values is supplied for AUTO_INCREMENT column
table->auto_increment_field_not_null= TRUE
else
table->auto_increment_field_not_null= FALSE
if (error)
return 1; *
if (table->auto_increment_field_not_null == FALSE)
...
table->auto_increment_field_not_null == FALSE
}
<-- table returned to table cache and later retrieved by open_table:
open_table():
assert(table->auto_increment_field_not_null)
mysql-test/r/trigger.result:
Bug#44653: Test result
mysql-test/t/trigger.test:
Bug#44653: Test case
sql/sql_insert.cc:
Bug#44653: Fix: Make sure to unset this field before returning in case of error
1. BUG#45357 - 5.1.35 crashes with Failing assertion: index->type & DICT_CLUSTERED
2. Also fixes the compilation problem when the flag -DUNIV_MUST_NOT_INLINE
Detailed revision comments:
r5340 | marko | 2009-06-17 12:11:49 +0300 (Wed, 17 Jun 2009) | 4 lines
branches/5.1: row_unlock_for_mysql(): When the clustered index is unknown,
refuse to unlock the record.
(Bug #45357, caused by the fix of Bug #39320).
rb://132 approved by Sunny Bains.
r5339 | marko | 2009-06-17 11:01:37 +0300 (Wed, 17 Jun 2009) | 2 lines
branches/5.1: Add missing #include "mtr0log.h" so that the code compiles
with -DUNIV_MUST_NOT_INLINE.
The merge from http://lists.mysql.com/commits/76678 caused the
growth_size parameter to the my_init_dynamic_array function to
be ignored. This patch corrects the problem.
mysys/hash.c:
Bug#43572 Handle failures from hash_init
Replacing the last parameter to my_init_dynamic_array with
growth_size.
Details:
- Limit the queries to character sets and collations
which are most probably available in all build types.
But try to preserve the intention of the tests.
- Remove the variants adjusted to some build types.
Note:
1. The results of the review by Bar are included.
2. I am not able to check the correctness of this patch
on any existing build type and any MySQL version.
So it could happen that the new test fails somewhere.
occasionally.
mysql_multi can call mysqld_safe. In doing this it's not changing the
current working directory. This may cause confusion in the case where
mysqld_multi is handling instances of servers of different versions
and the current working directory is the installation directory of one
of these servers.
Fixed by enhancing the meaning of basedir in [mysqldN] sections of
mysqld_multi. If specified, mysqld_multi will change the current
working directory to the basedir directory before starting the server
in mysqld_multi ... start ... and then change it back to what it was.
scripts/mysqld_multi.sh:
Bug #36654: optionally preserve, change and restore the cwd when
starting server instances
Failure to allocate memory for the hash->array element,
caused hash_init to return without initializing the other
members of the hash. Thus although the dynamic array
buffer may be allocated at a later point in the code, the
incompletely initialized hash caused fatal failures.
This patch moves the initialization of the other members
of the hash above the array allocation, so that the usage
of this hash will not result in fatal failures.
include/hash.h:
Bug#43572 Handle failures from hash_init
hash_inited is used to verify that the hash is
valid. After the change induced by the current
patch hash->array.buffer !=0 is not a valid check
for this condition, since, the dynamic array can
be allocated even at a later time. Bootstrap SQL
script is setting some variables, which are
actually not set due to this hash_inited issue.
Thus we get empty grant tables.
A better way to check if the hash is valid is
to verify that hash->blength is greater than 0.
mysys/hash.c:
Bug#43572 Handle failures from hash_init
Move the initialization of the other members
of the hash above the array allocation, so that
the usage of this hash will not result in fatal
failures.
Inconsistent behavior of session variable max_allowed_packet
(and net_buffer_length); only assignment to the global variable
has any effect, without this being obvious to the user.
The patch for Bug#22891 is backported to 5.0, making the two
session variables read-only. As this is a backport to GA
software, the error used when trying to assign to the read-
only variable is ER_UNKNOWN_ERROR. The error message is the
same as in 5.1+.
mysql-test/t/variables.test:
Tests are changed to account for the new semantics, and assignment to the read-only variables is added to test
the emission of the correct error message.
sql/set_var.cc:
Both max_allowed_packet and net_buffer_length are changed
to be of type sys_var_thd_ulong_session_readonly. ER_UNKNOWN_ERROR is used to indicate an attempt to assign
to an instance of a read-only variable.
sql/set_var.h:
Class sys_var_thd_ulong_session_readonly is added.
The problem: described in the bug report.
The fix:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
client/mysql.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/ha_ndbcluster.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/ha_ndbcluster_binlog.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/handler.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/log.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/mysqld.cc:
removed unnecessary line
sql/parse_file.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_acl.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_base.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_db.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_delete.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_partition.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_rename.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_show.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_table.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
sql/sql_view.cc:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
as argument for strxnmov function
The problem was that a pthread.h header used by gcc did not
declare the pthread_setscheprio, yet the function is implemented
by the function is implemented, causing a autoconf check to pass
and compilation with C++ to fail. The solution is to add a
autoconf check to ensure that the function is properly declared.
configure.in:
Check that the pthread_setschedprio is declared.
Large transactions and statements may corrupt the binary log if the size of the
cache, which is set by the max_binlog_cache_size, is not enough to store the
the changes.
In a nutshell, to fix the bug, we save the position of the next character in the
cache before starting processing a statement. If there is a problem, we simply
restore the position thus removing any effect of the statement from the cache.
Unfortunately, to avoid corrupting the binary log, we may end up loosing changes
on non-transactional tables if they do not fit in the cache. In such cases, we
store an Incident_log_event in order to stop the slave and alert users that some
changes were not logged.
Precisely, for every non-transactional changes that do not fit into the cache,
we do the following:
a) the statement is *not* logged
b) an incident event is logged after committing/rolling back the transaction,
if any. Note that if a failure happens before writing the incident event to
the binary log, the slave will not stop and the master will not have reported
any error.
c) its respective statement gives an error
For transactional changes that do not fit into the cache, we do the following:
a) the statement is *not* logged
b) its respective statement gives an error
To work properly, this patch requires two additional things. Firstly, callers to
MYSQL_BIN_LOG::write and THD::binlog_query must handle any error returned and
take the appropriate actions such as undoing the effects of a statement. We
already changed some calls in the sql_insert.cc, sql_update.cc and sql_insert.cc
modules but the remaining calls spread all over the code should be handled in
BUG#37148. Secondly, statements must be either classified as DDL or DML because
DDLs that do not get into the cache must generate an incident event since they
cannot be rolled back.
Change the default optimization level for Sun Studio to "-O1".
This is a workaround for a Sun Studio bug (see bug #41710
comments for details):
1. Use $GCC instead of $ac_cv_prog_gcc to check for gcc, since
the first one is the only documented way to do it.
2. Use $GXX instead of $ac_cv_prog_cxx_g to check for g++,
since the latter is set to "yes" when the C++ compiler accepts
"-g" which is the case for both g++ and CC.
3. When building with Sun Studio, set the default values for
CFLAGS/CXXFLAGS to "-O1", since unlike GCC, Sun Studio
interprets "-O" as "-xO3" (see the manual pages for cc and CC).
configure.in:
1. Use $GCC instead of $ac_cv_prog_gcc to check for gcc, since
the first one is the only documented way to do it.
2. Use $GXX instead of $ac_cv_prog_cxx_g to check for g++,
since the latter is set to "yes" when the C++ compiler accepts
"-g" which is the case for both g++ and CC.
3. When building with Sun Studio, set the default values for
CFLAGS/CXXFLAGS to "-O1", since unlike GCC, Sun Studio
interprets "-O" as "-xO3" (see the manual pages for cc and CC).
