without error
When using quick access methods for searching rows in UPDATE or
DELETE there was no check if a fatal error was not already sent
to the client while evaluating the quick condition.
As a result a false OK (following the error) was sent to the
client and the error was thus transformed into a warning.
Fixed by checking for errors sent to the client during
SQL_SELECT::check_quick() and treating them as real errors.
Fixed a wrong test case in group_min_max.test
Fixed a wrong return code in mysql_update() and mysql_delete()
This patch is a follow up to http://lists.mysql.com/commits/76678.
When an allocation failure occurs for the buffer in the dynamic
array, an error condition was being set. The dynamic array is
usable even if the memory allocation fails. Since in most cases
the thread can continue to work without any problems the error
condition should not be set here.
This patch adds logic to remove the error condition from being set
when the memory allocation for the buffer in dynamic array fails.
mutually-nested subqueries
Queries of the form
SELECT * FROM (SELECT 1) AS t1,
(SELECT 2) AS t2,...
(SELECT 32) AS t32
caused the "Too high level of nesting for select" error
as if the query has a form
SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM...
The table_factor parser rule has been modified to adjust
the LEX::nest_level variable value after every derived table.
sort_buffer_size cannot allocate
The NULL return from tree_insert() (on low memory) was not
checked for in Item_func_group_concat::add(). As a result
on low memory conditions a crash happens.
Fixed by properly checking the return code.
1. BUG#21704 - Renaming column does not update FK definition
2. Changes in mysql-test/include/mtr_warnings.sql so that the testcase
for BUG#21704 doesn't fail because of the warnings generated.
Detailed revision comments:
r5488 | vasil | 2009-07-09 19:16:44 +0300 (Thu, 09 Jul 2009) | 13 lines
branches/5.1:
Fix Bug#21704 Renaming column does not update FK definition
by checking whether a column that participates in a FK definition is being
renamed and denying the ALTER in this case.
The patch was originally developed by Davi Arnaut <Davi.Arnaut@Sun.COM>:
http://lists.mysql.com/commits/77714
and was later adjusted to conform to InnoDB coding style by me (Vasil),
I also added some more comments and moved the bug specific mysql-test to
a separate file to make it more manageable and flexible.
and base tables
myrg_attach_children() could reuse a buffer that was allocated
previously based on a definition of a child table. The problem
was that the child's definition might have been changed, so
reusing the buffer could lead to crashes or valgrind errors
under some circumstances.
Fixed by changing myrg_attach_children() so that the
rec_per_key_part buffer is reused only when the child table
have not changed, and reallocated otherwise (the old buffer is
deallocated if necessary).
BUG#45749 - Race condition in SET GLOBAL innodb_commit_concurrency=DEFAULT
Detailed revision comments:
r5419 | marko | 2009-06-25 16:11:57 +0300 (Thu, 25 Jun 2009) | 18 lines
branches/5.1: Merge r5418 from branches/zip:
------------------------------------------------------------------------
r5418 | marko | 2009-06-25 15:55:52 +0300 (Thu, 25 Jun 2009) | 5 lines
Changed paths:
M /branches/zip/ChangeLog
M /branches/zip/handler/ha_innodb.cc
M /branches/zip/mysql-test/innodb_bug42101-nonzero.result
M /branches/zip/mysql-test/innodb_bug42101-nonzero.test
M /branches/zip/mysql-test/innodb_bug42101.result
M /branches/zip/mysql-test/innodb_bug42101.test
branches/zip: Fix a race condition caused by
SET GLOBAL innodb_commit_concurrency=DEFAULT. (Bug #45749)
When innodb_commit_concurrency is initially set nonzero,
DEFAULT would change it back to 0, triggering Bug #42101.
rb://139 approved by Heikki Tuuri.
------------------------------------------------------------------------
1. Fixes build warnings caused by applying snapshot 5.1-ss5282
2. Fix the Makefile.am in storage/innobase to remove the header file
'fsp0types.h' which was added twice to fix build warning generated
after applying the 5.1-ss5282 snapshot
Detailed revision comments:
r5410 | marko | 2009-06-24 22:26:34 +0300 (Wed, 24 Jun 2009) | 2 lines
branches/5.1: Add missing #include "mtr0log.h" to avoid warnings
when compiling with -DUNIV_MUST_NOT_INLINE.
- when finding out a way to hide symbols, make decision basing
on compiler, not operating system.
- Sun Studio supports __hidden declaration specifier for this
purpose.
When the function exits with an error it was not
freeing the local Unique class instance.
Fixed my making sure all the places where the function
returns from are freeing the Unique instance
unnecessarily
The problem is that libmysqlclient.so is built with THREAD
undefined, while a client compiling against the same header
files will see THREAD as defined and definitions in
my_pthread.h will be included, possibly resulting in undefined
symbols that cannot be resolved with libmysqlclient.so.
The suggested solution is to require that clients wanting to
link with libmysqlclient.so should be built with
MYSQL_CLIENT_NO_THREADS defined. This requires a documentation
change, and more details for this will be supplied if this
patch is approved.
The MYSQL_CLIENT_NO_THREADS define was renamed from
UNDEF_THREADS_HACK, to get a more suitable (less suspicious)
name for the define. (The UNDEF_THREADS_HACK is retained for
backwards compatibility, though.)
This patch is also in anticipation of WL#4958, which will
remove this problem altogether by dropping the building of
libmysqlclient.
use partial primary key if another index can prevent filesort
The fix for bug #28404 causes the covering ordering indexes to be
preferred unconditionally over non-covering and ref indexes.
Fixed by comparing the cost of using a covering index to the cost of
using a ref index even for covering ordering indexes.
Added an assertion to clarify the condition the local variables should
be in.
purge_relay_logs() did not propagate an error happend in count_relay_log_space().
Fixed with the suggestesd setting the error= true.
Note, propagation generally out of purge_relay_logs() was fixed for Bug #44179,
and the issue does not exist in 6.0 thanks to a patch for WL#2775.
