Due to a BZR bug, that merge was done by the following command:
bzr merge -r 'revid:tor.didriksen@sun.com-20100527074248-6qtv0p1ugy6o1hjo..' <mysql-trunk-bugfixing path>
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080324111246-00461
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080414125521-40866
BUG#35274 - merge table doesn't need any base tables, gives
error 124 when key accessed
SELECT queries that use index against a merge table with empty
underlying tables list may return with error "Got error 124 from
storage engine".
The problem was that wrong error being returned.
mysql-test/r/merge.result:
Backport of
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080324111246-00461
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080414125521-40866
A test case for BUG#35274.
Modified a test case according to fix for BUG#35274. Key based
reads are now allowed for merge tables with no underlying tables
defined.
mysql-test/t/merge.test:
Backport of
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080324111246-00461
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080414125521-40866
A test case for BUG#35274.
Modified a test case according to fix for BUG#35274. Key based
reads are now allowed for merge tables with no underlying tables
defined.
storage/myisammrg/myrg_queue.c:
Backport of
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080324111246-00461
- revid:sp1r-svoj@mysql.com/june.mysql.com-20080414125521-40866
Return "end of file" error instead of "wrong index" error when
we got a merge table with empty underlying tables list.
In 5.1 we cannot rely on info->open_tables value when checking
if a merge table has no underlying tables defined.
Use info->tables instead.
when it should use index
Sometimes the LEFT/RIGHT JOIN with an empty table caused an
unnecessary filesort.
Sample query, where t1.i1 is indexed and t3 is empty:
SELECT t1.*, t2.* FROM t1 JOIN t2 ON t1.i1 = t2.i2
LEFT JOIN t3 ON t2.i2 = t3.i3
ORDER BY t1.i1 LIMIT 5;
The server erroneously used an item of empty outer-joined
table as a common constant of a Item_equal (multi-equivalence
expression).
By the fix for the bug 16590 the constant status of such
an item has been propagated to st_table::const_key_parts
map bits related to other Item_equal argument-related
key parts (those are obviously not constant in our case).
As far as test_if_skip_sort_order function skips constant
prefixes of testing keys, this caused an ignorance of
available indices, since some prefixes were marked as
constant by mistake.
mysql-test/r/order_by.result:
Test case for bug #38745.
mysql-test/t/order_by.test:
Test case for bug #38745.
sql/item.h:
Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
when it should use index
Item::is_outer_field() has been added and overloaded for
Item_field and Item_ref classes.
sql/item_cmpfunc.cc:
Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
when it should use index
Item_equal::update_const() and Item_equal::update_used_tables()
have been updated to not take into account the constantness
of outer-joined table items.
The problem is that if a NULL is stored in an Item_cache_decimal object,
the associated my_decimal object is not initialized. However, it is still
accessed when val_int() is called. The fix is to check for null_value
within val_int(), and return without accessing the my_decimal object when
the cached value is NULL.
Bug#52122 reports the same issue for val_real(), and this patch also includes
fixes for val_real() and val_str() and corresponding test cases from that
bug report.
Also, NULL is returned from val_decimal() when value is null. This will
avoid that callers access an uninitialized my_decimal object.
Made similar changes to all other Item_cache classes. Now all val_*
methods should return a well defined value when actual value is NULL.
mysql-test/r/type_decimal.result:
Updated result file with test cases for Bug#52168 and Bug#52122.
mysql-test/t/type_decimal.test:
Added test cases for Bug#52168 and Bug#52122.
sql/item.cc:
In Item_cache_*::val_* methods, return a well defined value
when actual value is NULL.
This is especially important for Item_cache_decimal since
otherwise one risk accessing an uninitialized my_decimal object.
sql/item.h:
Added method Item_cache::has_value() which returns TRUE if cache
object contains a non-null value.
For BINARY(N) strip trailing zeroes to make the error message nice-looking
mysql-test/r/errors.result:
test case
mysql-test/r/type_binary.result:
result fix
mysql-test/t/errors.test:
test case
sql/key.cc:
For BINARY(N) strip trailing zeroes to make the error message nice-looking
We should avoid any SHARE fields assignments as
this is shared structure and assignments may
affect other therads. To avoid this
copy of SHARE struct is created and
stored into TABLE struct which is
used in get_schema_coulumns_record later.
mysql-test/r/mdl_sync.result:
test case
mysql-test/t/mdl_sync.test:
test case
sql/sql_show.cc:
We should avoid any SHARE fields assignments as
this is shared structure and assignments may
affect other therads. To avoid this
copy of SHARE struct is created and
stored into TABLE struct which is
used in get_schema_coulumns_record later.
can now view the content of InnoDB System Tables through following
information schema tables:
information_schema.INNODB_SYS_TABLES
information_schema.INNODB_SYS_INDEXES
information_schema.INNODB_SYS_COUMNS
information_schema.INNODB_SYS_FIELDS
information_schema.INNODB_SYS_FOREIGN
information_schema.INNODB_SYS_FOREIGN_COLS
information_schema.INNODB_SYS_TABLESTATS
rb://330 Approved by Marko
data directory name command
The check_db_name function has been modified to validate tails of
#mysql50#-prefixed database names for compliance with MySQL 5.0
database name encoding rules (the check_table_name function call
has been reused).
mysql-test/r/renamedb.result:
Updated test case.
mysql-test/r/upgrade.result:
Test case for bug #53804.
mysql-test/t/renamedb.test:
Updated test case.
mysql-test/t/upgrade.test:
Test case for bug #53804.
sql/mysql_priv.h:
Bug #53804: serious flaws in the alter database .. upgrade
data directory name command
The check_mysql50_prefix has been added.
sql/sql_table.cc:
Bug #53804: serious flaws in the alter database .. upgrade
data directory name command
- The check_mysql50_prefix has been added.
- The check_n_cut_mysql50_prefix function has been refactored
to share code with new check_mysql50_prefix function.
sql/table.cc:
Bug #53804: serious flaws in the alter database .. upgrade
data directory name command
The check_db_name function has been modified to validate tails of
#mysql50#-prefixed database names for compliance with MySQL 5.0
database name encoding rules.
FOR UPDATE is causing a lock".
This patch tries to address problems which were exposed
during backporting of original patch to 5.1 tree.
- It ensures that we don't change locking behavior of simple
SELECT statements on InnoDB tables when they are executed
under LOCK TABLES ... READ and with @@innodb_table_locks=0.
Also we no longer pass TL_READ_DEFAULT/TL_WRITE_DEFAULT
lock types, which are supposed to be parser-only, to
handler::start_stmt() method.
- It makes check_/no_concurrent_insert.inc auxiliary scripts
more robust against changes in test cases that use them
and also ensures that they don't unnecessarily change
environment of caller.
mysql-test/include/check_concurrent_insert.inc:
Reset DEBUG_SYNC facility before and after using it in
auxiliary script. This makes this script more robust against
changes in test cases calling it. It also ensures that script
does not unnecessarily change environment of caller.
mysql-test/include/check_no_concurrent_insert.inc:
Reset DEBUG_SYNC facility before and after using it in
auxiliary script. This makes this script more robust against
changes in test cases calling it. It also ensures that script
does not unnecessarily change environment of caller.
mysql-test/r/innodb-lock.result:
Added coverage for LOCK TABLES ... READ behavior in
@@innodb_table_locks = 0 mode. This test also checks
that an appropriate type of lock is passed to
handler::start_stmt() method.
mysql-test/t/innodb-lock.test:
Added coverage for LOCK TABLES ... READ behavior in
@@innodb_table_locks = 0 mode. This test also checks
that an appropriate type of lock is passed to
handler::start_stmt() method.
sql/sql_base.cc:
Since we no longer set TL_READ as lock type for tables used
in simple SELECT right in the parser, in order to preserve
behavior for such statements on InnoDB tables when in
LOCK TABLES mode with @innodb_table_locks = 0,
check_lock_and_start_stmt() had to be changed to convert
TL_READ_DEFAULT to an appropriate type of read lock before
passing it to handler::start_stmt() method.
We do similar thing for TL_WRITE_DEFAULT as this lock type
is also supposed to be parser-only type.
As consequence read_lock_type_for_table() had to be
adjusted to behave properly when it is called from
check_lock_and_start_stmt() in prelocked mode.
Server crashes on 64bit linux with 'double free or corruption'
message, on 32bit mysql-test-run silently fails on bootstrap
stage. The problem is that FreeState() is called twice
for init_settings struct in _db_end_ function.
The fix is to remove superfluous FreeState() call.
Additional fix:
fixed discrepancy of result file when
debug & valgrind options are enabled
for MTR.
dbug/dbug.c:
The problem is that FreeState() is called twice
for init_settings struct in _db_end_ function.
The fix is to remove superfluous FreeState() call.
mysql-test/r/variables_debug.result:
fixed discrepancy of result file when
debug & valgrind options are enabled
for MTR.
mysql-test/t/variables_debug.test:
fixed discrepancy of result file when
debug & valgrind options are enabled
for MTR.
sql/set_var.cc:
fixed discrepancy of result file when
debug & valgrind options are enabled
for MTR.
The problem was that OPTMIZE TABLE was allowed to run on a table
in use by a transaction in a different connection. This caused
repeatable read to break.
This bug was fixed by the introduction of metadata locking, WL#4284.
OPTIMIZE TABLE will now be blocked until the transaction using the
table, has ended.
This patch contains a regression test added to innodb_mysql_lock.test
and no code changes.
Bug #50087 Interval arithmetic for Event_queue_element is not portable.
Subtraction of two unsigned months yielded a (very large) positive value.
Conversion of this to a signed value was not necessarily well defined.
Solution: do the subtraction on signed values.
mysql-test/r/events_scheduling.result:
Add test case.
mysql-test/t/events_scheduling.test:
Add test case.
sql/event_data_objects.cc:
Convert month to signed before doing the subtraction.
ha_myisam::index_first(uchar*)") at assert.c:81
Single-table DELETE crash/assertion similar to single-table
UPDATE bug 14272.
Same resolution as for the bug 14272:
Don't run index scan when we should use quick select.
This could cause failures because there are table handlers (like federated)
that support quick select scanning but do not support index scanning.
mysql-test/r/delete.result:
Test case for bug #53450.
mysql-test/t/delete.test:
Test case for bug #53450.
sql/sql_delete.cc:
Bug #53450: Crash / assertion "virtual int
ha_myisam::index_first(uchar*)") at assert.c:81
The mysql_delete function has been modified to not to use
init_read_record_idx instead of init_read_record for the
quick select.
for ALTER TABLE, LOAD DATA).
ROW_COUNT is now assigned according to the following rules:
- In my_ok():
- for DML statements: to the number of affected rows;
- for DDL statements: to 0.
- In my_eof(): to -1 to indicate that there was a result set.
We derive this semantics from the JDBC specification, where int
java.sql.Statement.getUpdateCount() is defined to (sic) "return the
current result as an update count; if the result is a ResultSet
object or there are no more results, -1 is returned".
- In my_error(): to -1 to be compatible with the MySQL C API and
MySQL ODBC driver.
- For SIGNAL statements: to 0 per WL#2110 specification. Zero is used
since that's the "default" value of ROW_COUNT in the diagnostics area.
sql/protocol.cc:
Fix a typo.
sql/sql_class.h:
- Introduce THD::get_row_count_func() / THD::set_row_count_func();
- Remove the CF_HAS_ROW_COUNT define
sql/sql_parse.cc:
CF_HAS_ROW_COUNT was eliminated.
NULL from outer join query
Problem: optimising MIN/MAX() queries without GROUP BY clause
by replacing the aggregate expression with a constant, we may set it
to NULL disregarding the fact that there may be outer joins involved.
Fix: don't replace MIN/MAX() with NULL if there're outer joins.
Note: the fix itself is just
- if (!count)
+ if (!count && !outer_tables)
set to NULL
The rest of the patch eliminates repeated code to improve speed
and for easy maintenance of the code.
mysql-test/r/group_by.result:
Fix for bug#52051: Aggregate functions incorrectly returns
NULL from outer join query
- test result.
mysql-test/t/group_by.test:
Fix for bug#52051: Aggregate functions incorrectly returns
NULL from outer join query
- test case.
sql/opt_sum.cc:
Fix for bug#52051: Aggregate functions incorrectly returns
NULL from outer join query
- optimising MIN/MAX() queries without GROUP BY clause by
replacing them with a constant, take into account that
there're may be outer joins involved.
- repeated code for MIN/MAX optimization in the opt_sum_query()
eliminated by introducing new functions that read MIN/MAX values
using index and combining MIN/MAX cases to one.
update statements
Only SELECT statements report any examined rows in the slow
log. Slow UPDATE, DELETE and INSERT statements report 0 rows
examined, unless the statement has a condition including a
SELECT substatement.
This patch adds counting of examined rows for the UPDATE and
DELETE statements. An INSERT ... VALUES statement will still
not report any rows as examined.
sql/sql_class.h:
Added more docs for THD::examined_row_count.
sql/sql_delete.cc:
Add incrementing thd->examined_row_count.
sql/sql_update.cc:
Add incrementing thd->examined_row_count.
remember range endpoints
The Loose Index Scan optimization keeps track of a sequence
of intervals. For the current interval it maintains the
current interval's endpoints. But the maximum endpoint was
not stored in the SQL layer; rather, it relied on the
storage engine to retain this value in-between reads. By
coincidence this holds for MyISAM and InnoDB. Not for the
partitioning engine, however.
Fixed by making the key values iterator
(QUICK_RANGE_SELECT) keep track of the current maximum endpoint.
This is also more efficient as we save a call through the
handler API in case of open-ended intervals.
The code to calculate endpoints was extracted into
separate methods in QUICK_RANGE_SELECT, and it was possible to
get rid of some code duplication as part of fix.
Conflicts:
Text conflict in mysql-test/r/grant.result
Text conflict in mysql-test/t/grant.test
Text conflict in mysys/mf_loadpath.c
Text conflict in sql/slave.cc
Text conflict in sql/sql_priv.h
Conflicts:
Text conflict in mysql-test/r/explain.result
Text conflict in mysql-test/t/explain.test
Text conflict in sql/net_serv.cc
Text conflict in sql/sp_head.cc
Text conflict in sql/sql_priv.h
The fix actually reverts the change introduced
by the patch for bug 51494.
The fact is that patches for bugs 52177&48419
fix bugs 51194&50575 as well.
mysql-test/r/innodb_mysql.result:
test case
mysql-test/t/innodb_mysql.test:
test case
sql/sql_select.cc:
reverted wrong fix for bug 51494
truncates text/blob to 766 chars
mysqldump and SELECT ... INTO OUTFILE truncated long BLOB/TEXT
values to size of 766 bytes (MAX_FIELD_WIDTH or 255 * 3 + 1).
The select_export::send_data method has been modified to
reallocate a conversion buffer for long field data.
mysql-test/r/mysqldump.result:
Test case for bug #53088.
mysql-test/r/outfile_loaddata.result:
Test case for bug #53088.
mysql-test/t/mysqldump.test:
Test case for bug #53088.
mysql-test/t/outfile_loaddata.test:
Test case for bug #53088.
sql/sql_class.cc:
Bug #53088: mysqldump with -T & --default-character-set set
truncates text/blob to 766 chars
The select_export::send_data method has been modified to
reallocate a conversion buffer for long field data.
greedy_search optimizer_search_depth=0
The algorithm inside restore_prev_nj_state failed to
properly update the counters within the NESTED_JOIN
tree. The counter was decremented each time a table in the
node was removed from the QEP, the correct thing to do being
only to decrement it when the last table in the child node
was removed from the plan. This lead to node counters
getting negative values and the plan thus appeared
impossible. An assertion caught this.
Fixed by not recursing up the tree unless the last table in
the join nest node is removed from the plan
data is selected or not
Temporary and permanent tables should live in different
namespaces. In this case, resolving a permanent table
name gave the temporary table, resulting in a name
collision.
The bug happened under the following condition:
- there was a user variable of type REAL, containing NULL value
- there was a table with a NOT_NULL column of any type but REAL, having
default value (or auto increment);
- a row was inserted into the table with the user variable as value.
A warning was emitted here.
The problem was that handling of NULL values of REAL type was not properly
implemented: it didn't expect that REAL NULL value can be assigned to other
data type.
Basically, the problem was that set_field_to_null() was used instead of
set_field_to_null_with_conversions().
The fix is to use the right function, or more generally, to allow conversion of
REAL NULL values to other data types.
