But Should Be "Zero Rows"
After applying the innodb snapshot 5.0-ss5406 for bug#40565, the windows push build
tests failed because of the missing cast of void * pointer in row0sel.c file
Informed the innodb developers and received patch by email.
Some collations--including cp1250_czech_cs,latin2_czech_cs,
ucs2/utf8_czech_ci, ucs2/utf8_danish_ci--are not being
sorted correctly by the IBMDB2I storage engine. This
was being caused because the sort order used by DB2 is
incompatible with the order expected by MySQL.
This patch removes support for the cp1250_czech_cs and
latin2_czech_cs collations because it has been determined
that the sort order used by DB2 is incompatible with the
order expected by MySQL. Users needing a czech collation
with IBMDB2I are encouraged to use a Unicode-based collation
instead of these single-byte collations. This patch also
modifies the DB2 sort sequence used for ucs2/utf8_czech_ci
and ucs2/utf8_danish_ci collations to better match the
sorting expected by MySQL. This will only affect indexes
or tables that are newly created through the IBMDB2I storage
engine. Existing IBMDB2I tables will retain the old sort
sequence until recreated.
format." warnings
Despite the fact that a statement would be filtered out from binlog, a
warning would still be thrown if it was issued with the LIMIT.
This patch addresses this issue by checking the filtering rules before
printing out the warning.
The TABLE::reginfo.impossible_range is used by the optimizer to indicate
that the condition applied to the table is impossible. It wasn't initialized
at table opening and this might lead to an empty result on complex queries:
a query might set the impossible_range flag on a table and when the query finishes,
all tables are returned back to the table cache. The next query that uses the table
with the impossible_range flag set and an index over the table will see the flag
and thus return an empty result.
The open_table function now initializes the TABLE::reginfo.impossible_range
variable.
such as quit and shutdown
Logging to slow log can produce an undetermined value for
Rows_examined in special cases. In debug mode this manifests
itself as any of the various marker values used to mark
uninitialized memory on various platforms.
If logging happens on a THD object that hasn't performed any
row reads (on this or any previous connections), the
THD::examined_row_count may be uninitialized. This patch adds
initialization for this attribute.
No automated test cases are added, as for this to be
meaningful, we need to ensure that we're using a THD
fulfilling the above conditions. This is hard to do in the
mysql-test-run framework. The patch has been verified
manually, however, by restarting mysqld and running the test
included with the bug report.
The problem is that the one phase commit function failed to
properly end a empty transaction. The solution is to ensure
that the transaction cleanup procedure is invoked even for
empty transactions.
The test case added failed sporadically on PB. This is due to the
fact that the user thread in some cases is waiting for slave IO
to stop and then check the error number. Thence, sometimes the
user thread would race for the error number with IO thread.
This post push fix addresses this by replacing the wait for slave
io to stop with a wait for slave io error (as it seems it was
added in 6.0 also after patch on which this is based was
pushed). This implied backporting wait_for_slave_io_error.inc
from 6.0 also.
Because of a regression introduced by bug#19027 the option --enable-foobar
doesn't work anymore for any plugin 'foobar'. The reason is that plugin
names are tristate options variables with optional parameters and integer
values are not accepted. Since the 'enable' prefix attempts to assign '1'
to the option the operation fails.
This patch translates any number n assigned to a plugin variable of type ENUM
to be the corresponding enumerated item. As a side effect --enable-foobar and
--disable-foobar will also start working again.
BUG#40565 - Update Query Results in "1 Row Affected" But Should Be "Zero Rows"
Detailed revision comments:
r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines
branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565
(Update Query Results in "1 Row Affected" But Should Be "Zero Rows").
Also, add a test case for Bug #40565.
rb://128 approved by Heikki Tuuri
------------------------------------------------------------------------
r3590 | marko | 2008-12-18 15:33:36 +0200 (Thu, 18 Dec 2008) | 11 lines
branches/5.1: When converting a record to MySQL format, copy the default
column values for columns that are SQL NULL. This addresses failures in
row-based replication (Bug #39648).
row_prebuilt_t: Add default_rec, for the default values of the columns in
MySQL format.
row_sel_store_mysql_rec(): Use prebuilt->default_rec instead of
padding columns.
rb://64 approved by Heikki Tuuri
------------------------------------------------------------------------
BUG#38479 - valgrind warnings in show table status for innodb tables
Detailed revision comments:
r5080 | vasil | 2009-05-22 14:45:34 +0300 (Fri, 22 May 2009) | 6 lines
branches/5.0:
Fix Bug#38479 valgrind warnings in show table status for innodb tables
by initializing prebuilt->hint_need_to_fetch_extra_cols.
In Item_param::set_from_user_var
value.cs_info.character_set_client is set
to 'fromcs' value. It's wrong, it should be set to
thd->variables.character_set_client.
> ------------------------------------------------------------
> 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.
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).
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)
