too much memory. Instead, either create the equvalent SEL_TREE manually, or create only two ranges that
strictly include the area to scan
(Note: just to re-iterate: increasing NOT_IN_IGNORE_THRESHOLD will make optimization run slower for big
IN-lists, but the server will not run out of memory. O(N^2) memory use has been eliminated)
mysql-test/r/func_in.result:
Testcase for BUG#15872
mysql-test/t/func_in.test:
Testcase for BUG#15872
sql/item.cc:
BUG#15872: Added Item_decimal::set_decimal_value()
sql/item.h:
UG#15872: Added Item_decimal::set_decimal_value()
sql/item_cmpfunc.h:
BUG#15872: Added in_vector::create_item(), in_vector::value_to_item() and their implementations in concrete
classes.
sql/opt_range.cc:
BUG#15872: Don't run the range analyzer on "t1.keypart NOT IN (const1, ..., )", as that
consumes too much memory. Instead, either
A) create the equivalent SEL_TREE manually, making use of the fact that item_not_in->array
has an ordered IN-list, or
B) create only two ranges: (-inf|NULL) < X < min_value_from_in_list, max_value_from_in_list < X
(Choose #B if the IN-list has > 10K elements)
sql/sql_table.cc:
Fix for bug #7643: ALTER TABLE fails for CSV, EXAMPLE, ARCHIVE engines
- issue an ER_NOT_SUPPORTED_YET if an engine doesn't support ALTER TABLE.
mysql-test/r/func_time.result:
Fix for bug #18501: Server crashes with monthname().
- test case
mysql-test/t/func_time.test:
Fix for bug #18501: Server crashes with monthname().
- test case
sql/item_timefunc.cc:
Fix for bug #18501: Server crashes with monthname().
- check null_value as well.
supported in SP but not in PS": just enable them in prepared
statements, the supporting functionality was implemented when
they were enabled in stored procedures.
mysql-test/r/ps.result:
Bug#19308: test results fixed.
mysql-test/r/ps_1general.result:
Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now
allowed in prepared statements.
mysql-test/r/sp-dynamic.result:
Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now
allowed in prepared statements.
mysql-test/t/ps.test:
Add a test case for Bug#19308 "REPAIR/OPTIMIZE/ANALYZE supported
in SP but not in PS"
mysql-test/t/ps_1general.test:
Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now
allowed in prepared statements.
sql/sql_prepare.cc:
Enable ANALYZE, OPTIMIZE, REPAIR in prepared statements.
into mysql.com:/usr/local/mysql/mysql-5.0-mtr-fix
mysql-test/mysql-test-run.pl:
Auto merged
mysql-test/t/case.test:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
mysql-test/r/case.result:
SCCS merged
trigger fails".
In cases when CONVERT_TZ() function was used in trigger or stored function
(or in stored procedure which was called from trigger or stored function)
error about non existing '.' table was reported.
Statements that use CONVERT_TZ() function should have time zone related
tables in their table list. tz_init_table_list() function which is used
to produce part of table list containing those tables didn't set
TABLE_LIST::db_length/table_name_length members properly. As result time
zone tables needed for CONVERT_TZ() function were incorrectly handled by
prelocking algorithm and "Table '.' doesn't exist' error was emitted.
This fix changes tz_init_table_list() in such way that it properly inits
TABLE_LIST::table_name_length/db_length members and thus produces table list
which can be handled by prelocking algorithm correctly.
mysql-test/r/timezone2.result:
Added test for bug #11081 "Using a CONVERT_TZ function in a stored function
or trigger fails".
mysql-test/t/timezone2.test:
Added test for bug #11081 "Using a CONVERT_TZ function in a stored function
or trigger fails".
sql/tztime.cc:
Now tz_init_table_list() inits table_name_length and db_length members in
TABLE_LIST objects, so table lists produced with its help can be handled
by prelocking algorithm properly.
Also two clean-ups are included:
- Now we use MY_TZ_TABLES_COUNT instead of magical number 4 in places where
it is appropriate.
- TZ_NAMES_ENTRY structure was converted to Tz_names_entry class in order
to emphasize its non-POD nature.
sql/tztime.h:
Added MY_TZ_TABLES_COUNT constant to be used as number of time zone related
tables which are needed for dynamical loading of time zone descriptions.
Update User_level_lock::thread_id on acquiring an existing lock,
and reset it on lock release.
mysql-test/r/func_misc.result:
Add result for bug#16501.
mysql-test/t/func_misc.test:
Add test case for bug#16501.
sql/item_func.cc:
Update User_level_lock::thread_id on acquiring an existing lock,
and reset it on lock release (for safety).
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0
mysql-test/r/rpl_temporary.result:
Auto merged
mysql-test/t/rpl_temporary.test:
Auto merged
sql/sql_base.cc:
Auto merged
The fix refines the algorithm of generating DROPs for binlog.
Temp tables with common pseudo_thread_id are clustered into one query.
Consequently one replication event per pseudo_thread_id is generated.
mysql-test/r/rpl_temporary.result:
results
mysql-test/t/rpl_temporary.test:
Creating temp tables associated with a set of pseudo_thread_id values within a connection.
The aim is to see that slave digest master's binlog consisting of DROP temprorary tables.
sql/sql_base.cc:
close_temporary_tables is rewritten to generate sequence of DROP temprorary tables with common preudo_thread_id stored in temp table definition.
accounting non-ai32 in tmpkeyval. This changeset is supposed to be specifically for 4.1.
Another changeset is going to push into 5.
sql/sql_base.cc:
correction due to uint4korr definition: can not sizeof on not ia32.
Backporting a changeset made for 5.0. Comments from there:
The fix refines the algorithm of generating DROPs for binlog.
Temp tables with common pseudo_thread_id are clustered into one query.
Consequently one replication event per pseudo_thread_id is generated.
mysql-test/r/rpl_temporary.result:
results changed
mysql-test/t/rpl_temporary.test:
test to generate problematic drop in binlog to feed it to restarting slave
to see no stop.
sql/sql_base.cc:
change in drop temprorary tables alg in close_temporary_tables.
Error was emitted when one tried to select information from view which used
merge algorithm and which also had CONVERT_TZ() function in its select list.
This bug was caused by wrong assumption that global table list for view
which is handled using merge algorithm begins from tables belonging to
the main select of this view. Nowadays the above assumption is not true only
when one uses convert_tz() function in view's select list, but in future
other cases may be added (for example we may support merging of views
with subqueries in select list one day). Relying on this false assumption
led to the usage of wrong table list for field lookups and therefor errors.
With this fix we explicitly use pointer to the beginning of main select's
table list.
mysql-test/r/timezone_grant.result:
Added additional test case for bug#15153 "CONVERT_TZ() is not allowed in
all places in VIEWs" that checks that usage of CONVERT_TZ() function in view
does not require additional privileges.
mysql-test/r/view.result:
Added test case for bug#15153 "CONVERT_TZ() is not allowed in all places in
VIEWs".
mysql-test/t/timezone_grant.test:
Added additional test case for bug#15153 "CONVERT_TZ() is not allowed in
all places in VIEWs" that checks that usage of CONVERT_TZ() function in view
does not require additional privileges.
mysql-test/t/view.test:
Added test case for bug#15153 "CONVERT_TZ() is not allowed in all places in
VIEWs".
sql/sql_view.cc:
mysql_make_view():
We should not assume that global table list for view which is handled using
merge algorithm begins from tables belonging to the main select of this
view. Nowadays the above assumption is not true only when one uses
convert_tz() function in view's select list, but in future other cases
may be added (for example we may support merging of views with subqueries
in select list one day). So let us instead explicitly use pointer to the
beginning of main select's table list.
Simply exclude INFORMATION_SCHEMA from LOAD DATA FROM MASTER just like
we exclude the `mysql` database.
There's no test for this, because it requires an unfiltered 'LOAD DATA
FROM MASTER' which is too likely to cause chaos (such as when running
the test suite against an external server).
sql/repl_failsafe.cc:
Exclude information_schema from LOAD DATA FROM MASTER.
Do not reset value of LAST_INSERT_ID() in sub-statement.
mysql-test/r/rpl_insert_id.result:
Add result for bug#15728.
mysql-test/r/sp.result:
Add result for bug#15728.
mysql-test/t/rpl_insert_id.test:
Add test case for bug#15728.
mysql-test/t/sp.test:
Add test case for bug#15728.
sql/sql_class.cc:
Do not reset value of LAST_INSERT_ID() in sub-statement.
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
mysql-test/r/order_by.result:
Added a test case for bug #18767.
mysql-test/t/order_by.test:
Added a test case for bug #18767.
sql/sql_lex.h:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_parse.cc:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_select.cc:
Fixed bug #18767.
Changed the condition on which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_union.cc:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_yacc.yy:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence. In the same way is handled the SELECT in
(SELECT ... LIMIT n) ORDER BY order list.
Yet if there is neither ORDER BY nor LIMIT in the single-select
union construct
(SELECT ...) ORDER BY order_list
then it is still handled as simple select with an order clause.
Bug #15684: @@version_* are not all SELECTable
Added the appropriate information as read-only system variables, and
also removed some special-case handling of @@version along the way.
@@version_bdb was added, but isn't included in the test because it
depends on the presence of BDB.
mysql-test/r/variables.result:
Update results
mysql-test/t/variables.test:
Fix error from setting @@version, reset sql_select_limit to avoid confusion
in later tests, and add new regression tests.
sql/item_func.cc:
Remove special-case handling of VERSION, it's just a read-only server
variable like the others now.
sql/set_var.cc:
Add system_time_zone and various version-related system variables
SQL_WARNINGS and SQL_NOTES were being displayed with SHOW_BOOL, but they
are system variables that need SHOW_SYS to be used.
mysql-test/r/variables.result:
Add new results
mysql-test/t/variables.test:
Add new regression test
sql/set_var.cc:
Fix display of sql_notes and sql_warnings in SHOW VARIABLES.
sql/ha_archive.cc:
Modifications for more of a lazy approach to opening up archive files for writing.
sql/ha_archive.h:
Added a variable to determine state, and a new method for encapsulating the opening of archive writers.
The SQL standard doesn't allow to use in HAVING clause fields that are not
present in GROUP BY clause and not under any aggregate function in the HAVING
clause. However, mysql allows using such fields. This extension assume that
the non-grouping fields will have the same group-wise values. Otherwise, the
result will be unpredictable. This extension allowed in strict
MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING
capabilities.
The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
"non-grouping field '%-.64s' is used in %-.64s clause". This message is
supposed to be used for reporting errors when some field is not found in the
GROUP BY clause but have to be present there. Use cases for this message are
this bug and when a field is present in a SELECT item list not under any
aggregate function and there is GROUP BY clause present which doesn't mention
that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
being more descriptive.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for
HAVING clause is found in the SELECT item list only.
sql/share/errmsg.txt:
Added the new ER_NON_GROUPING_FIELD_USED error message for the bug#14169.
mysql-test/t/having.test:
Added test case for the bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
mysql-test/r/having.result:
Added test case for the bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
sql/sql_select.cc:
Added TODO comment to change the ER_WRONG_FIELD_WITH_GROUP to more detailed ER_NON_GROUPING_FIELD_USED message.
sql/item.cc:
Fixed bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
The resolve_ref_in_select_and_group() function now reports the
ER_NON_GROUPING_FIELD_FOUND error if the strict MODE_ONLY_FULL_GROUP_BY mode
is set and the field for HAVING clause is found in the SELECT item list only.
After a locking error the open table(s) were not fully
cleaned up for reuse. But they were put into the open table
cache even before the lock was tried. The next statement
reused the table(s) with a wrong lock type set up. This
tricked MyISAM into believing that it don't need to update
the table statistics. Hence CHECK TABLE reported a mismatch
of record count and table size.
Fortunately nothing worse has been detected yet. The effect
of the test case was that the insert worked on a read locked
table. (!)
I added a new function that clears the lock type from all
tables that were prepared for a lock. I call this function
when a lock failes.
No test case. One test would add 50 seconds to the
test suite. Another test requires file mode modifications.
I added a test script to the bug report. It contains three
cases for failing locks. All could reproduce a table
corruption. All are fixed by this patch.
This bug was not lock timeout specific.
sql/lock.cc:
Bug#18544 - LOCK TABLES timeout causes MyISAM table corruption
Resetting the lock type in the open table(s) lock data
after a locking error.
