Two cases in ha_partition::extra() was missing
(HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH)
which only is currently used by NDB (which not uses ha_partition)
mysql-test/r/partition.result:
Added result for test of Bug #30484
mysql-test/t/partition.test:
Added test for Bug #30484
sql/ha_partition.cc:
Added HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH
in ha_partition::extra to do nothing
(Only currently used in NDB, which is not dependent of ha_partition)
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build
mysql-test/suite/rpl/r/rpl_row_tabledefs_2myisam.result:
Auto merged
mysql-test/suite/rpl/r/rpl_row_tabledefs_3innodb.result:
Auto merged
cmake list are auto-generated and thus still required. Correct fix
not yet known.
bdb/CMakeLists.txt:
Revert previous change, it is incorrect as those files are automatically
generated.
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
mysql-test/r/alter_table.result:
Auto merged
mysql-test/r/create.result:
Auto merged
mysql-test/r/ctype_collate.result:
Auto merged
mysql-test/r/ctype_recoding.result:
Auto merged
mysql-test/r/default.result:
Auto merged
mysql-test/r/gis.result:
Auto merged
mysql-test/r/grant.result:
Auto merged
mysql-test/r/information_schema.result:
Auto merged
mysql-test/r/key.result:
Auto merged
mysql-test/r/mysql.result:
Auto merged
mysql-test/r/ps_1general.result:
Auto merged
mysql-test/r/sp.result:
Auto merged
mysql-test/r/type_enum.result:
Auto merged
mysql-test/r/type_ranges.result:
Auto merged
mysql-test/r/show_check.result:
manual merge
mysql-test/t/information_schema.test:
manual merge
sql/sql_show.cc:
manual merge
added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)
mysql-test/r/alter_table.result:
result fix
mysql-test/r/create.result:
result fix
mysql-test/r/ctype_collate.result:
result fix
mysql-test/r/ctype_recoding.result:
result fix
mysql-test/r/default.result:
result fix
mysql-test/r/gis.result:
result fix
mysql-test/r/grant.result:
result fix
mysql-test/r/information_schema.result:
result fix
mysql-test/r/key.result:
result fix
mysql-test/r/mysql.result:
result fix
mysql-test/r/ps_1general.result:
result fix
mysql-test/r/show_check.result:
result fix
mysql-test/r/sp.result:
result fix
mysql-test/r/type_enum.result:
result fix
mysql-test/r/type_ranges.result:
result fix
mysql-test/t/information_schema.test:
test case
into magare.gmz:/home/kgeorge/mysql/autopush/B30639-5.1-opt
mysql-test/r/select.result:
Auto merged
mysql-test/t/select.test:
Auto merged
sql/sql_lex.cc:
Auto merged
The parser uses ulonglong to store the LIMIT number. This number
then is stored into a variable of type ha_rows. ha_rows is either
4 or 8 byte depending on the BIG_TABLES define from config.h
So an overflow may occur (and LIMIT becomes zero) while storing an
ulonglong value in ha_rows.
Fixed by :
1. Using the maximum possible value for ha_rows on overflow
2. Defining BIG_TABLES for the windows builds (to match the others)
include/config-win.h:
Bug #30639: turn on BIG_TABLES for windows
mysql-test/r/select.result:
Bug #30639: test case
mysql-test/t/select.test:
Bug #30639: test case
sql/sql_lex.cc:
Bug #30639: Use the maximum possible number on overflow
of LIMIT. This is valid because there won't be more rows
anyway.
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
mysql-test/suite/rpl/r/rpl_row_tabledefs_2myisam.result:
Auto merged
mysql-test/suite/rpl/r/rpl_row_tabledefs_3innodb.result:
Auto merged
into trift2.:/MySQL/M51/push-5.1
config/ac-macros/misc.m4:
Auto merged
mysql-test/suite/rpl/r/rpl_row_tabledefs_2myisam.result:
Auto merged
mysql-test/suite/rpl/r/rpl_row_tabledefs_3innodb.result:
Auto merged
mysql-test/t/disabled.def:
Auto merged
sql/field.cc:
Auto merged
sql/field.h:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/log_event.h:
Auto merged
sql/rpl_record.cc:
Auto merged
sql/rpl_rli.h:
Auto merged
sql/rpl_utility.cc:
Auto merged
sql/rpl_utility.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_cache.cc:
Auto merged
Merge with 5.0-opt.
mysql-test/r/binlog_unsafe.result:
Merge with 5.0-opt.
mysql-test/r/events_bugs.result:
Merge with 5.0-opt.
mysql-test/r/events_trans.result:
Merge with 5.0-opt.
mysql-test/r/sp.result:
Merge with 5.0-opt.
mysql-test/r/sp_gis.result:
Merge with 5.0-opt.
mysql-test/r/xml.result:
Merge with 5.0-opt.
mysql-test/suite/rpl/r/rpl_incident.result:
Merge with 5.0-opt.
mysql-test/suite/rpl/r/rpl_loaddata_fatal.result:
Merge with 5.0-opt.
mysql-test/suite/rpl/r/rpl_udf.result:
Merge with 5.0-opt.
mysql-test/suite/rpl_ndb/r/rpl_ndb_extraCol.result:
Merge with 5.0-opt.
mysql-test/suite/ndb/r/ndb_dd_basic.result:
Merge with 5.0-opt.
mysql-test/suite/ndb/r/ndb_dd_ddl.result:
Merge with 5.0-opt.
mysql-test/suite/ndb/r/ndb_gis.result:
Merge with 5.0-opt.
mysql-test/suite/ndb/r/ndb_row_format.result:
Merge with 5.0-opt.
mysql-test/suite/ndb/r/ndb_single_user.result:
Merge with 5.0-opt.
The optimizer sets index traversal in reverse order only if there are
used key parts that are not compared to a constant.
However using the primary key as an ORDER BY suffix rendered the check
incomplete : going in reverse order must still be used even if
all the parts of the secondary key are compared to a constant.
Fixed by relaxing the check and set reverse traversal even when all
the secondary index keyparts are compared to a const.
Also account for the case when all the primary keys are compared to a
constant.
mysql-test/r/innodb_mysql.result:
Bug #31001: test case
mysql-test/t/innodb_mysql.test:
Bug #31001: test case
sql/sql_select.cc:
Bug #31001:
- account for the case when all the primary key parts are compared
to a constant
- force test_if_skip_sort_order to go backwards over the key even
when the number of keyparts used is the same as the number of
keyparts equal to a constant. (because of the primary key
suffix).
into mysql.com:/home/psergey/mysql-5.1-bug27927
mysql-test/r/type_bit.result:
Auto merged
mysql-test/t/type_bit.test:
Auto merged
sql/item_sum.cc:
Auto merged
- The bug was caused by COUNT(DISTINCT ...) code using Unique object in
a way that assumed that BIT(N) column occupies a contiguous space in
temp_table->record[0] buffer.
- The fix is to make COUNT(DISTINCT ...) code instruct create_tmp_table to
create temporary table with column of type BIGINT, not BIT(N).
mysql-test/r/type_bit.result:
BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
- Testcase
mysql-test/t/type_bit.test:
BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
- Testcase
sql/item_sum.cc:
BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
- Make COUNT(DISTINCT ...) code instruct create_tmp_table to create
temporary table with BIGINT, not BIT(N) column.
- Introduced val_int_endpoint() function which converts between func
argument intervals and func value intervals for monotonic functions.
- Made partition interval analyzer use part_expr->val_int_endpoint()
to check if the edge values should be included.
mysql-test/r/partition_pruning.result:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Testcase
mysql-test/t/partition_pruning.test:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Testcase
sql/item.cc:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Added Item_field::val_int_endpoint() implementation
sql/item.h:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Added Item::val_int_endpoint() which converts intervals from argument
space to function value space for unary monotonic functions.
sql/item_timefunc.cc:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Added val_int_endpoint() for TO_DAYS and YEAR functions.
sql/item_timefunc.h:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Added val_int_endpoint() for TO_DAYS and YEAR functions.
sql/partition_info.h:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Removed partition_info::range_analysis_include_bounds as it is no longer
needed.
sql/sql_partition.cc:
BUG#27927: Partition pruning not optimal with TO_DAYS and YEAR functions
- Make partition interval analyzer use part_expr->val_int_endpoint() to
check if the edge values should be included.
