When a connection is dropped any remaining temporary table is also automatically
dropped and the SQL statement of this operation is written to the binary log in
order to drop such tables on the slave and keep the slave in sync. Specifically,
the current code base creates the following type of statement:
DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;
Unfortunately, appending the database to the table name in this manner circumvents
the replicate-rewrite-db option (and any options that check the current database).
To solve the issue, we started writing the statement to the binary as follows:
use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
The crash happens because select_union object is used as result set
for queries which have derived tables.
select_union use temporary table as data storage and if
fields count exceeds 10(count of values for procedure ANALYSE())
then we get a crash on fill_record() function.
mysql-test/r/analyse.result:
test result
mysql-test/r/subselect.result:
result fix
mysql-test/t/analyse.test:
test case
mysql-test/t/subselect.test:
test fix
sql/sql_yacc.yy:
The crash happens because select_union object is used as result set
for queries which have derived tables.
select_union use temporary table as data storage and if
fields count exceeds 10(count of values for procedure ANALYSE())
then we get a crash on fill_record() function.
Problem was that the partition containing NULL values
was pruned away, since '2001-01-01' < '2001-02-00' but
TO_DAYS('2001-02-00') is NULL.
Added the NULL partition for RANGE/LIST partitioning on TO_DAYS()
function to be scanned too.
Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).
mysql-test/include/partition_date_range.inc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added include file to decrease test code duplication
mysql-test/r/partition_pruning.result:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added test results
mysql-test/r/partition_range.result:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Updated test result.
This fix adds the partition containing NULL values to
the list of partitions to be scanned.
mysql-test/t/partition_pruning.test:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added test case
sql/item.h:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS.
sql/item_timefunc.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Calculate the number of days as return value even for invalid dates.
This is so that pruning can be used even for invalid dates.
sql/opt_range.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Fixed a bug that added ALLOW_INVALID_DATES to sql_mode
(SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST
partitioned table would add it).
sql/partition_info.h:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Resetting ret_null_part when a single partition is to be used, this
to avoid adding the NULL partition.
sql/sql_partition.cc:
Bug#20577: Partitions: use of to_days() function leads to selection failures
Always include the NULL partition if RANGE or LIST.
Use the returned value for the function for pruning, even if
it is marked as NULL, so that even '2000-00-00' can be
used for pruning, even if TO_DAYS('2000-00-00') is NULL.
Changed == to >= in get_next_partition_id_list to avoid
crash if part_iter->part_nums is not correctly setup.
There were a problem since pruning uses the field
for comparison (while evaluate_join_record uses longlong),
resulting in pruning failures when comparing DATE to DATETIME.
Fix was to always comparing DATE vs DATETIME as DATETIME,
by adding ' 00:00:00' to the DATE string.
And adding optimization for comparing with 23:59:59, so that
DATETIME_col > '2001-02-03 23:59:59' ->
TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead
of '>='.
mysql-test/r/partition_pruning.result:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated result-file
mysql-test/t/partition_pruning.test:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added testcases.
sql-common/my_time.c:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
removed duplicate assignment.
sql/item.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Changed field_is_equal_to_item into field_cmp_to_item, to
better handling DATE vs DATETIME comparision.
sql/item.h:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Updated comment
sql/item_timefunc.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Added optimization (pruning) of DATETIME where time-part is
23:59:59
sql/opt_range.cc:
Bug#46362: Endpoint should be set to false for TO_DAYS(DATE)
Using the new stored_field_cmp_to_item for better pruning.
that was already analyzed by Oracle: EXPLAIN can return 3 or 4 in "rows"; using replace_column to work around this.
mysql-test/include/index_merge2.inc:
replace "rows" column of some EXPLAINs by "#", if told so
mysql-test/r/index_merge_innodb.result:
result update
mysql-test/t/index_merge_innodb.test:
tell index_merge2.inc to accept random "rows" values in some EXPLAINs; we don't do this in index_merge_myisam.test
which has no randomness here.
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.
The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.
This patch borrows code and ideas from Martin Hansson's patch.
mysql-test/r/type_newdecimal.result:
Add test case result for Bug#45261. Also, update test case to
reflect that an additive operation increases the precision of
the resulting type by 1.
mysql-test/t/type_newdecimal.test:
Add test case for Bug#45261
sql/field.cc:
Added DBUG_ASSERT to ensure object's invariant is maintained.
Implement method to create a field to hold a decimal value
from an item.
sql/field.h:
Explain member variable. Add method to create a new decimal field.
sql/item.cc:
The precision should only be capped when storing the value
on a table. Also, this makes it impossible to calculate the
integer part if Item::decimals (the scale) is larger than the
precision.
sql/item.h:
Simplify calculation of integer part.
sql/item_cmpfunc.cc:
Do not limit the precision. It will be capped later.
sql/item_func.cc:
Use new method for allocating a new decimal field.
Add a specialized method for retrieving the precision
of a user variable item.
sql/item_func.h:
Add method to return the precision of a user variable.
sql/item_sum.cc:
Use new method for allocating a new decimal field.
sql/my_decimal.h:
The integer part could be improperly calculated for a decimal
with 31 digits in the fractional part.
sql/sql_select.cc:
Use new method which truncates the integer or decimal parts
as needed.
INSERT ... SELECT ...
Problem was that when bulk insert is used on an empty
table/partition, it disables the indexes for better
performance, but in this specific case it also tries
to read from that partition using an index, which is
not possible since it has been disabled.
Solution was to allow index reads on disabled indexes
if there are no records.
Also reverted the patch for bug#38005, since that was a workaround
in the partitioning engine instead of a fix in myisam.
mysql-test/r/partition.result:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
updated result file
mysql-test/t/partition.test:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Added testcase
sql/ha_partition.cc:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
reverted the patch for bug#38005, since that was a workaround
around this problem, not needed after fixing it in myisam.
storage/myisam/mi_search.c:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX
when there are no rows.
(temporary) TABLE, crash
Problem: if one has an open "HANDLER t1", further "TRUNCATE t1"
doesn't close the handler and leaves handler table hash in an
inconsistent state, that may lead to a server crash.
Fix: TRUNCATE should implicitly close all open handlers.
Doc. request: the fact should be described in the manual accordingly.
mysql-test/r/handler_myisam.result:
Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
(temporary) TABLE, crash
- test result.
mysql-test/t/handler_myisam.test:
Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
(temporary) TABLE, crash
- test case.
sql/sql_delete.cc:
Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
(temporary) TABLE, crash
- remove all truncated tables from the HANDLER's hash.
view manipulations
The bespoke flag was not properly reset after last call to
fill_record. Fixed by resetting in caller mysql_update.
mysql-test/r/auto_increment.result:
Bug#46616: Test result.
mysql-test/t/auto_increment.test:
Bug#46616: Test case.
sql/sql_update.cc:
Bug#46616: Fix.
view that has Group By
Table access rights checking function check_grant() assumed
that no view is opened when it's called.
This is not true with nested views where the inner view
needs materialization. In this case the view is already
materialized when check_grant() is called for it.
This caused check_grant() to not look for table level
grants on the materialized view table.
Fixed by checking if a view is already materialized and if
it is check table level grants using the original table name
(not the ones of the materialized temp table).
on SHOW CREATE TRIGGER + MERGE table
Problem: SHOW CREATE TRIGGER erroneously relies on fact
that we have the only underlying table for a trigger
(wrong for merge tables).
Fix: remove erroneous assert().
mysql-test/r/merge.result:
Fix for bug #46614: Assertion in show_create_trigger()
on SHOW CREATE TRIGGER + MERGE table
- test result.
mysql-test/t/merge.test:
Fix for bug #46614: Assertion in show_create_trigger()
on SHOW CREATE TRIGGER + MERGE table
- test case.
sql/sql_show.cc:
Fix for bug #46614: Assertion in show_create_trigger()
on SHOW CREATE TRIGGER + MERGE table
- unnecessary assert() removed as we may have more than 1
tables open e.g. for a merge table.
Replication SQL thread does not set database default charset to
thd->variables.collation_database properly, when executing LOAD DATA binlog.
This bug can be repeated by using "LOAD DATA" command in STATEMENT mode.
This patch adds code to find the default character set of the current database
then assign it to thd->db_charset when slave server begins to execute a relay log.
The test of this bug is added into rpl_loaddata_charset.test
The test for the 45806 entry in our bug DB got applied twice,
in different places for the "view.test" and "view.result" files.
The fix is to simply remove the erroneous insertion.
All committed result differences have either been verified by me or copied from Oracle's provided
results (storage/innodb_plugin/mysql-test/*.result, storage/innodb_plugin/mysql-test/patches).
mysql-test/r/information_schema.result:
queries changed a bit
mysql-test/r/information_schema_db.result:
queries changed a bit
mysql-test/r/innodb-autoinc.result:
importing piece from storage/innodb_plugin/mysql-test/innodb-autoinc.result
mysql-test/r/innodb.result:
result close to storage/innodb_plugin/innodb.result, except 4095 pages instead of 8191, which makes
sense as Summit runs with a buffer pool of 64M, whereas the mentioned result file was made with
a buffer pool of 128M.
mysql-test/r/mysqlshow.result:
InnoDB I_S tables have arrived
mysql-test/suite/funcs_1/r/is_columns_is.result:
queries changed a bit
mysql-test/suite/funcs_1/r/is_columns_is_embedded.result:
queries changed a bit
mysql-test/suite/funcs_1/r/is_tables_is.result:
queries changed a bit
mysql-test/suite/funcs_1/t/is_columns_is.test:
making I_S queries ignore InnoDB I_S tables
mysql-test/suite/funcs_1/t/is_columns_is_embedded.test:
making I_S queries ignore InnoDB I_S tables
mysql-test/suite/funcs_1/t/is_tables_is.test:
making I_S queries ignore InnoDB I_S tables
mysql-test/suite/innodb/r/innodb-zip.result:
result update
mysql-test/suite/innodb/t/innodb-zip.test:
439, as size of prefix key, throws error with certain system zlib (ubuntu
"intrepid") but not with zlib bundled with MySQL, because zlib's
compressBound() are different (and used by InnoDB's page_zip_empty_size()).
mysql-test/suite/sys_vars/r/innodb_file_per_table_basic.result:
result update
mysql-test/suite/sys_vars/r/innodb_lock_wait_timeout_basic.result:
result update
mysql-test/suite/sys_vars/r/innodb_sync_spin_loops_basic_32.result:
result update (default value is 30 in the plugin, 20 in the builtin)
mysql-test/suite/sys_vars/r/innodb_sync_spin_loops_basic_64.result:
result update (default value is 30 in the plugin, 20 in the builtin)
mysql-test/suite/sys_vars/r/table_definition_cache_basic.result:
result update (default value is 400 in Summit)
mysql-test/suite/sys_vars/t/innodb_file_per_table_basic.test:
variable is writable in the plugin (patch from Oracle)
mysql-test/suite/sys_vars/t/innodb_lock_wait_timeout_basic.test:
variable is per-session in the plugin (patch from Oracle)
mysql-test/t/information_schema.test:
making I_S queries ignore InnoDB I_S tables
mysql-test/t/information_schema_db.test:
making I_S queries ignore InnoDB I_S tables
mysql-test/t/innodb-autoinc.test:
importing piece from storage/innodb_plugin/mysql-test/innodb-autoinc.test
mysql-test/t/innodb.test:
importing most of storage/innodb_plugin/t/innodb.test. Most replace_result were not needed (no path printed), some where (for --embedded).
mysql-test/t/mysqlshow.test:
output of test now depends on InnoDB or not InnoDB. As there is no way to make mysqlshow
produce a single output in those two cases (no way to make it exclude InnoDB I_S
tables), let the test depend on InnoDB, it isn't a very selective condition, and the
test is simple enough.
storage/innobase/CMakeLists.txt:
thanks Vlad for the noticing () vs {}
Problem 1:
When the 'Using index' optimization is used, the optimizer may still - after
cost-based optimization - decide to use another index in order to avoid using
a temporary table. But when this happens, the flag to the storage engine to
read index only (not table) was still set. Fixed by resetting the flag in the
storage engine and TABLE structure in the above scenario, unless the new index
allows for the same optimization.
Problem 2:
When a 'ref' access method was employed by cost-based optimizer, (when the column
is non-NULLable), it was assumed that it needed no initialization if 'quick' access
methods (since they are based on range scan). When ORDER BY optimization overrides
the decision, however, it expects to have this initialized and hence crashes.
Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's
'ref' access.
mysql-test/r/order_by.result:
Bug#46454: Test result.
mysql-test/t/order_by.test:
Bug#46454: Test case.
sql/sql_select.cc:
Bug#46454:
Problem 1 fixed in make_join_select()
Problem 2 fixed in test_if_skip_sort_order()
sql/table.h:
Bug#46454: Added comment to field.
when partition is reoganized.
Problem was that table->timestamp_field_type was not changed
before copying rows between partitions.
fixed by setting it to TIMESTAMP_NO_AUTO_SET as the first thing
in fast_alter_partition_table, so that all if-branches is covered.
column on partitioned table
An assertion 'ASSERT_COULUMN_MARKED_FOR_READ' is failed if the query
is executed with index containing double column on partitioned table.
The problem is that assertion expects all the fields which are read,
to be in the read_set.
In this query only the field 'a' is in the readset as the tables in
the query are joined by the field 'a' and so the assertion fails
expecting other field 'b'.
Since the function cmp() is just comparison of two parameters passed,
the assertion is not required.
Fixed by removing the assertion in the double fields comparision
function and also fixed the index initialization to do ordered
index scan with RW LOCK which ensures all the fields from a key are in
the read_set.
Note: this bug is not reproducible with other datatypes because the
assertion doesn't exist in comparision function for other
datatypes.
mysql-test/r/partition.result:
Testcase for BUG#45816
mysql-test/t/partition.test:
Testcase for BUG#45816
sql/field.cc:
Removed the assertion ASSERT_COLUMN_MARED_FOR_READ in Field_double::cmp()
function
sql/ha_partition.cc:
Fixed index_int() method to make it initialize the read_set properly if
ordered index scan with RW lock is requested.
bzr branch mysql-5.1-performance-version mysql-trunk # Summit
cd mysql-trunk
bzr merge mysql-5.1-innodb_plugin # which is 5.1 + Innodb plugin
bzr rm innobase # remove the builtin
Next step: build, test fixes.
Install procedure does not copy *.inc files located under the mysql-test/t directory.
Therefore, this patch moves the rpl_trigger.inc to the mysql-test/include directory.
The test case fails sporadically on Windows while trying to overwrite an unused
binary log. The problem stems from the fact that MySQL on Windows does not
immediately unlock/release a file while the process that opened and closed it is
still running. In BUG 38603, this issue was circumvented by stopping the MySQL
process, copying the file and then restarting the MySQL process.
Unfortunately, such facilities are not available in the 5.0. Other approaches
such as stopping the slave and issuing change master do not work because the relay
log file and index are not closed when a slave is stopped. So to fix the problem,
we simply don't run on windows the part of the test that was failing.
engine to the partition_csv test. Also remove test case that was
duplicated. Fix connection procedure with the embedded server.
mysql-test/r/partition.result:
Update test case result.
mysql-test/r/partition_csv.result:
Update test case result.
mysql-test/t/partition.test:
Move test cases to the partition_csv test.
mysql-test/t/partition_csv.test:
Move tests from partition.test and remove duplicate.
Tweaky connection procedure to work with embedded.
when used with --tab
1) New syntax: added CHARACTER SET clause to the
SELECT ... INTO OUTFILE (to complement the same clause in
LOAD DATA INFILE).
mysqldump is updated to use this in --tab mode.
2) ESCAPED BY/ENCLOSED BY field parameters are documented as
accepting CHAR argument, however SELECT .. INTO OUTFILE
silently ignored rests of multisymbol arguments.
For the symmetrical behavior with LOAD DATA INFILE the
server has been modified to fail with the same error:
ERROR 42000: Field separator argument is not what is
expected; check the manual
3) Current LOAD DATA INFILE recognizes field/line separators
"as is" without converting from client charset to data
file charset. So, it is supposed, that input file of
LOAD DATA INFILE consists of data in one charset and
separators in other charset. For the compatibility with
that [buggy] behaviour SELECT INTO OUTFILE implementation
has been saved "as is" too, but the new warning message
has been added:
Non-ASCII separator arguments are not fully supported
This message warns on field/line separators that contain
non-ASCII symbols.
client/mysqldump.c:
mysqldump has been updated to call SELECT ... INTO OUTFILE
statement with a charset from the --default-charset command
line parameter.
mysql-test/r/mysqldump.result:
Added test case for bug #30946.
mysql-test/r/outfile_loaddata.result:
Added test case for bug #30946.
mysql-test/t/mysqldump.test:
Added test case for bug #30946.
mysql-test/t/outfile_loaddata.test:
Added test case for bug #30946.
sql/field.cc:
String conversion code has been moved from check_string_copy_error()
to convert_to_printable() for reuse.
sql/share/errmsg.txt:
New WARN_NON_ASCII_SEPARATOR_NOT_IMPLEMENTED message has been added.
sql/sql_class.cc:
The select_export::prepare() method has been modified to:
1) raise the ER_WRONG_FIELD_TERMINATORS error on multisymbol
ENCLOSED BY/ESCAPED BY field arguments like LOAD DATA INFILE;
2) warn with a new WARN_NON_ASCII_SEPARATOR_NOT_IMPLEMENTED
message on non-ASCII field or line separators.
The select_export::send_data() merhod has been modified to
convert item data to output charset (see new SELECT INTO OUTFILE
syntax). By default the BINARY charset is used for backward
compatibility.
sql/sql_class.h:
The select_export::write_cs field added to keep output
charset.
sql/sql_load.cc:
mysql_load has been modified to warn on non-ASCII field or
line separators with a new WARN_NON_ASCII_SEPARATOR_NOT_IMPLEMENTED
message.
sql/sql_string.cc:
New global function has been added: convert_to_printable()
(common code has been moved from check_string_copy_error()).
sql/sql_string.h:
New String::is_ascii() method and new global convert_to_printable()
function have been added.
sql/sql_yacc.yy:
New syntax: added CHARACTER SET clause to the
SELECT ... INTO OUTFILE (to complement the same clause in
LOAD DATA INFILE). By default the BINARY charset is used for
backward compatibility.
We disallow the partitioning of a log table. You could however
partition a table first, and then point logging to it. This is
not only against the docs, it also crashes the server.
We catch this case now.
mysql-test/r/partition.result:
results for 40281
mysql-test/t/partition.test:
test for 40281: show that trying to log to partitioned table fails rather
to crash the server
sql/ha_partition.cc:
Signal that we no longer support logging to partitioned tables,
as per the docs.
sql/sql_partition.cc:
Some commands like "USE ..." have no select, yet we may try
to parse partition info after their execution if user set a
partitioned table as log target. This shouldn't lead to a
NULL-deref/crash.
