Select of the test could not perform deterministically, because the table remains to be
updatable by the running event handler.
Fixed with changing verification to use a logical values instead of comparison
with a pre-recorded results.
The problem is that since MyISAM's concurrent_insert is on by
default some concurrent SELECT statements might not see changes
made by INSERT statements in other connections, even if the
INSERT statement has returned.
The solution is to disable concurrent_insert so that INSERT
statements returns after the data is actually visible to other
statements.
Bug#36033 - Test funcs_1.processlist_val_ps fails on Windows
Bug#36034 - Test parts.part_supported_sql_func_<eng> fails on Windows
Bug#36036 - Test parts.partition_alter1_<eng> fails on Windows
Bug#36037 - Test parts.partition_alter2_<eng> fails on Windows
Bug#36038 - Test parts.partition_basic_<engine> failing on Windows
Bug#36039 - Test parts.partition_engine_<eng> fails on Windows
Bug#36040 - Test parts.partition_syntax_<eng> fails on Windows
Changeset to fix multiple 5.1.24-rc build bugs on Windows platforms.
Many of these bugs had the same root causes.
for ENGINE=MRG_MYISAM (should be optimized out).
Before WL#3281 MERGE engine had the HA_NOT_EXACT_COUNT flag
unset, and it worked with COUNT optimization as desired.
After the removal of the HA_NOT_EXACT_COUNT flag neither
HA_STATS_RECORDS_IS_EXACT (opposite to former HA_NOT_EXACT_COUNT
flag) nor modern HA_HAS_RECORDS flag were not added to MERGE
table flag mask.
1. The HA_HAS_RECORDS table flag has been set.
2. The ha_myisammrg::records method has been overridden to
calculate total number of records in underlying tables.
When a zero length is provided to the my_decimal_length_to_precision
function along with unsigned_flag set to false it returns a negative value.
For queries that employs temporary tables may cause failed assertion or
excessive memory consumption while temporary table creation.
Now the my_decimal_length_to_precision and the my_decimal_precision_to_length
functions take unsigned_flag into account only if the length/precision
argument is non-zero.
The function test_if_skip_sort_order ignored any covering index used for ref
access of a table in a query with ORDER BY if this index was incompatible
with the ORDER BY list and there was another covering index compatible with
this list.
As a result sub-optimal execution plans were chosen for some queries with
ORDER BY clause.
impossible WHERE/HAVING clause
(subselect_single_select_engine::exec).
Allocation and initialization of joined table list t1, t2... of
subqueries like:
NOT IN (SELECT ... FROM t1,t2,... WHERE 0)
is optimized out, however server tries to traverse this list.
Grouping or ordering of long values in not indexed BLOB/TEXT columns
with GBK or BIG5 charsets crashes the server.
MySQL server uses sorting (the filesort procedure) in the temporary
table to evaluate the GROUP BY clause in case of lack of suitable index.
That procedure takes into account only first @max_sort_length bytes
(system variable, usually 1024) of TEXT/BLOB sorting key string.
The my_strnxfrm_gbk and my_strnxfrm_big5 fill temporary keys
with data of whole blob length instead of @max_sort_length bytes
length. That buffer overrun has been fixed.
Add ChangeLog if it exists
- Removed separate 'normal+rowrepl' test run, not needed any longer
- Removed separate 'rpl' test run, included in main test run already
- Renamed some test "comments", to use similar naming style
- Limited one of the Cluster test runs to 'ndb' and 'rpl_ndb' suites
- Reordered test runs, to be aligned with Windows test runs
mysql.spec.sh:
- No longer including the "Example" storage engine
- Added to configure "--without-ENGINE" if not to compile engine as plugin
Among two claimed artifacts the critical one is in that the Table map of
a query following the failing with a duplicate key error CREATE-SELECT is skipped from
instantionating (and thus binlogging). That leads to sending a "chopped" group of the data
row-events without the table map head to the slave.
The slave can not apply the only data row events.
It's not easy to force the slave to react with an error in such a case (the second complaint
on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event
handler is a common situation which normally designates the event has to be filtered out
basing on the repliation do/ingore rules decision.
Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in
select_create::abort().
No error is reported if by chance the table map was not been binlogged.
Leaving this out to resolve with considering how to combine the do/ingore rules with the situation
when erronoulsy the Table_map is not written to binlog.
The problem is that when upgrading the event table, the sql_mode
column was always being added instead of being updated to list new
sql_mode values, causing upgrades of the event which already have
a sql_mode column to not be updated to the new sql_mode values.
The solution is to always add first a stub sql_mode column and
subsequently update the column to the new sql_mode values.
If excluding Federated, make sure dynamic plugin is not built
Makefile.am:
Only run cluster test when compiled with cluster
lib_sql.cc:
Work around for Visual Studio 2003, that lacks vsnprintf() but has _vsnprintf()
Corrects build problems embedded on Windows
Makefile.am:
Install .sym or mysqld-debug if exists
query_cache_debug.test, query_cache_debug.result:
Set more resonable query cache size (bug#35749)
CMakeLists.txt:
Added missing stacktrace.c
Problems were caused by modifications of
- the server
- HANDLER FOR SQLSTATE '00000' is now rejected (bug fix)
affects several ..._storedproc* tests
- improved error message
affects the ..._trig_03e
- improved content of information_schema.COLUMNS about
information_schema.REFERENTIAL_CONSTRAINTS
affects is_columns_is
- the content of the community build (collations)
affects charset_collation_3
